Константин Хлопов
прежде чем утверждать о возможности многопоточного VCL... нужно вообще знать в чем траблы и когда возникают....
в твоем примере с label'ом... один поток пишет в буферную переменную а второй поток читает из нее в label... разумеется и чтение и запись закрыты критическими секциями, а выигрыш в многопоточности есть. Ты можешь исполнять запрос скажем минуту в отдельном потоке и в это же время заниматься другими вещами. Если этих "других вещей" нет, то нехрен многопоточник городить.

В случае с гридом... есть мысль... только в качестве буферной переменной юзать нечто куда будет выливаться результат запроса. Как недостаток следует признать необходимость полного fetch записей.

Alexey Kovyazin
по поводу "gds32 не поддерживает многопоточный доступ"... Странно... Во-первых, я это использую, причем тестировал в режиме когда это удовольствие обязано было свалится... Да и потом... dll одна... а приложения запускаем два... уже получилась многопоточность...

Константин Хлопов

мда.....
это видно комне относилась "реализация" Execute.... По мойму я уже писал... что так нельзя...нужно перекрывать критическими секциями.... а ты снова за свое... Да и я не вижу смысла многозадачности, если тут происходит работа фактически в главном потоке... вот если у тебя было бы вместо тупого инкремента скажем разложение Фурье, то тут был бы выигрыш...

zahodun

для твоего случая... работает у меня подобная штука и на удивление стабильно и безотказно. Да и время очень жестко задано. В терх потоках живет (погоди всеж в четерех) общение с прогой по телнету, чтение данных с COM-порта каждые 100мс и общение с базой, которое может затянуться и на секунду и даже подольше... При том что результат чтения отображается в окне и в принципе я думаю можно редактирование прикрутить. А ларчик просто открывается. Например в потоке 1 тебе надо чтоб была форма (подчеркиваю это не главный поток в обычном понимании). Тогда ты именно в этом потоке создаешь форму (create) и в нем же даешь команду на отображение (show). Далее, дабы й тебя поток не прекратил свое существование слишком оперативно (то есть сразу после создания формы) оформляешь следующую последовательность команд:



синтаксис дельфей, но думаю переведешь. Sleep обязательно, дабы проток не грузил комп по напрасну. Можно этим спипом рулить приоритет своеобразно весьма. Разумеется, если мы завершаем поток, то необходимо убить форму. Точно так же можно создавать сколь угодно много форм. Причем разумеется в одном потоке. Объмен информацией между потоками я осуществляю через очередь. сразу предупрежу. Та что идет стандартно нельзя использовать, так как не поддерживает многопоточность. Я писал свою, если надо поделюсь, но разумеется написана на дельфе.
И в заключении скажу, что вся эта конструкция работает дополнительно и в dll и прекрасно функционирует.

датамодуль это просто контейнер и все. У него нет собственной очереди сообщений, поэтому вообще говоря не важно где его создавать. Я говорил все в отношении форм где и происходят все накладки при одновременном доступе из двух потоков. Если ты подменишь датамодуль на форму, то тут уже можно говрить осмыслено и в твоем случае форма окажется "привязана" к главному потоку. Привязана именно очередью.
Немного проясню откуда все траблы. Например мы пытаемся модифицировать label во втором потоке. При присваивании значения, оно автоматически отображается на форме и пишется в некую область памяти. В самый неприятный момент в очередь главного потока падает событие WM_PAINT, которое заставляет перерисоваться окно и соответственно и изменить информацию в той же самой области памяти, где и шарится второй поток. В итоге, происходят вещи, предсказать которые, крайне трудно.
Что происходит в случае когда окно создано и показано в коде второго потока? Ничего страшного кроме провязывания внутренних переменных библиотеки VCL и WinAPI. Когда же мы принудительно вызываем функцию ProgressMessages происходит обработка событий в очередях тех окон, которые созданы именно в этом потоке, откуда был вызов . В итоге, мы получаем, что работой окна управляет именнонаш вторичный поток и не касается его главный. Для доказательства, можно заблокировать цикл который я приводил, остановив тем самым второй поток. ОКНО ОБНОВЛЯТЬСЯ НЕ БУДЕТ Это я проверял и в принципе и дошел до этих идей именно через подобные тесты. (плюс хелп разумеется)

Теперь о твое проблеме. Рисуем в дизайнере нужную нам форму, со всеми элементами редактирования и прочего. Если нужен датамодуль, то можем создавать его где угодно(только разумеется он должен быть создан перед тем как его форма будет юзать, это важно отследить) либо в этой же форме. А потом создаем и показываем форму в функции потока. Все будет работать железно. Потому как это будет фактически однопоточник. Но я бы не советовал юзать компоненты, которые юзаются в форме в другом потоке. Иначе мы напоримся на те же грабли. Обмен можно осуществлять через очередь, но подчеркну еще раз стандартную очередь (компонента TQueue) использовать нельзя. Она не предназначена для обращения к ней из многих потоков, только внутри одного.