UI в отдельном потоке

[sts]

Существует ли вариант LCL или аналог работающий в отдельном потоке?
т.е. чтобы OnClick работал в основном потоке а формы рисовались в отдельном и соответственно нажатие кнопки в потоке UI пробрасывало вызов OnClick в основной.
аналогично DB компоненты работают в основном а дбгрид в UI

[WAYFARER]

Подозреваю что нет. И тут скорее дело даже не в LCL, а в библиотеках виджетов. Что в windows все окна, формы и контролы WinAPI обязаны жить в том потоке, где находится message loop. Этот цикл сообщений существует только в одном потоке. Что в GTK, все вызовы GTK должны выполняться СТРОГО из главного потока.
В общем все визуальные компоненты и события живут только в главном GUI-потоке и никак иначе. Это фундаментальное нерушимое правило)))
Разве что Qt допускает несколько потоков, но виджеты жёстко привязаны к потоку где они были созданы. То есть у каждого окна есть “свой” event loop, и обращаться к нему из других потоков запрещено, так что вряд ли это тебе поможет.

Добавлено спустя 11 минут 4 секунды:

т.е. чтобы OnClick работал в основном потоке а формы рисовались в отдельном и соответственно нажатие кнопки в потоке UI пробрасывало вызов OnClick в основной.
аналогично DB компоненты работают в основном а дбгрид в UI

Получается наоборот. DB компоненты выносить в рабочие потоки. Ну или если нужна полная изоляция, то дели на два процесса (грубо говоря клиент-сервер).

[sts]

Подозреваю что нет.

проблеме, а точнее задаче более 20 лет, зря разработчики так плотно сфокусировались на VCL, есть в ней ряд фундаментальных недостатков, да они нормальны для первых версий делфы, а вот потом надо было переработать.

Получается наоборот.

я под основным потоком имею ввиду APP поток в котором запускается функция MAIN. нужно чтобы в нем работала логика программы, как и сейчас, а вот для форм запускался отдельный UI поток, который является основным для UI компонент и в нем они создаются. DB компоненты работают APP потоке а визуализация в подбрасывается в UI поток.
Я делал прототип такого приложения в делфе, для этого надо разделить UI контрол на две части, первая доступна из APP потока, вторая из UI потока,в LCL разделение уже сделано, надо UI поток добавить

[stikriz11]

Вы ставите телегу перед лошадью, по моему. ГУИ должна работать в потоке приложения, а свои обработчики делайте в отдельных нитках - так правильно. По крайней мере для офисных программ. Ну, а если вы игроделы, то нафига вам вообще окна и гуи?

[sts]

Вы ставите телегу перед лошадью, по моему.

тут речь о том чтобы UI компоненты поддерживали многопоточность а какой поток главный вторично, когда вы запускаете обработчик в отдельном потоке вам все равно надо учесть что пока он не отработает, другие "кнопки" должны дождаться его завершения, например, соединение с бд одно (ну и спец кнопка прервать), в итоге имеем кучу ручных проверок, а надо чтоб само работало, в силу архитектуры

[stikriz11]

когда вы запускаете обработчик в отдельном потоке вам все равно надо учесть что пока он не отработает,

Пока от отрабатывает с мордой аплиухи можно делать все сто угодно. Лочить надо ограниченное количество контролов. Как правило кнопку, которая запускает наш поток. А когда он закончит работу, надо вызвать синхронизе - вся морда встанет, отдать результат основному потоку из нитки. Это делается так. Это очень простая и логичная схема. Зачем делать по другому? Даже философски если рассуждать, то основной поток в нашем мире и тут же сидит макрообъект - человек. А параллельные нитки квантовой механики запускаются в параллельном мире, и пока оно там живет, нет никакой возможности понять что происходит в волновой функции... И только квантовая запутанность позволяет нам вернуть результат в наш мир, но с уничтожением параллельной нитки. Все логично же.

Добавлено спустя 7 минут 21 секунду:

ну и спец кнопка прервать

В цикле потока проверять переменную через мьютекс. Именно для этого оно и придумано.

Добавлено спустя 32 минуты 26 секунд:
Нитки надо хранить либо в списке, либо в ссылке. Потому, что если пользователь захочет закрыть аплиуху, вы должны им сделать либа вайт фо и не закрывать, либо терминате и вайт фо. Так что, все равно где-то придется проверять, мол, не пора ли остановиться.