svnvlad

При чем тут PostMessage - не понятно.

_Navy_При вынесении архивации в доп. поток не нужно ни то, ни другоеТС ни слова не спрашивал про потоки (может они и не подпрыгнули в этой задаче), а его засыпали, как обычно.

krapotkinчерез SynchronizeВот тут уж тогда лучше через PostMessage. Зачем к кривой технологии приучать, чтобы потом грабли разгребать и в итоге уходить от Synchronize.

white_niggerYuRockЗачем к кривой технологии приучать, чтобы потом грабли разгребать и в итоге уходить от Synchronize.А зачем приучать к велосипедостроению, вместо того, чтобы использовать специально предоставленный механизм?Т.к. этот специальный механизм не всегда работоспособен, не говоря уже о его тормознутости и ограниченности. Обсуждалось уже много раз, снова не хочется.

Про какие велосипеды ты говоришь - не совсем понятно только. Работа с окнами идет через сообщения, посылаемые ф-циями Send/PostMessage.
Синхронизация между потоками достигается логикой архитектуры программы и, если надо, объектами синхронизации. Всё, точка. Никак не кривыми костылями.

white_niggerYuRock.к. этот специальный механизм не всегда работоспособен, не говоря уже о его тормознутости и ограниченности. Обсуждалось уже много раз, снова не хочется.
Про какие велосипеды ты говоришь - не совсем понятно только. Работа с окнами идет через сообщения, посылаемые ф-циями Send/PostMessage.
Синхронизация между потоками достигается логикой архитектуры программы и, если надо, объектами синхронизации. Всё, точка. Никак не кривыми костылями.Если ты не умеешь готовить кошек - это не значит что они невкусные. Подтяни матчасть по TThread, там не только Synchronize.
А ты подтяни не знаю, что, и скажи, что будет, когда потоки, созданные тобою, вызовут Synchronize, а в основном потоке в это время

1. Не был вызван Application.Run
2. При обработке какого-то сообщения через цикл из Application.Run (например в Button1Click) был создан еще один цикл обработки сообщений, например, GetMessage, WaitMessage или MsgWaitForMultiplyObjects+PeekMessage и крутится себе, всё обрабатывает, закончится тогда-то и тогда-то, когда нужно будет.

И если твой ответ будет правильным, то он будет таков: "Они все намертво повиснут в лучшем случае до того момента, пока что-то не случится, при чем это что-то никоим образом не относится к синхронизации данных, доступ к которым ты пытаешься синхронизировать".

Хочешь разгребать подобные проблемы? Вперед.

Это первое. Второе.
Метод синхронизации данных через очередь (хотя в данном случае это не через очередь, Synchronize - это глючный костыль к очереди, вот Send/PostMessage - это через очередь) нужен тогда, когда он нужен. И больше никогда.
Синхронизировать данные всегда через очередь - мега-убогий способ, т.к. все ждут каждого, даже если это не требуется. А через очередь главного потока - супер-мега-убогий, ибо все ждут еще и окончания обработки в потоке очереди и других сообщений, не требующих вообще никакой синхронизации, а она может занимать, скажем мягко, некоторое время.

schiYuRockчто будет, когда потоки, созданные тобою, вызовут Synchronize, а в основном потоке в это время

1. Не был вызван Application.Run
2. При обработке какого-то сообщения через цикл из Application.Run (например в Button1Click) был создан еще один цикл обработки сообщений, например, GetMessage, WaitMessage или MsgWaitForMultiplyObjects+PeekMessage и крутится себе, всё обрабатывает, закончится тогда-то и тогда-то, когда нужно будет.


Ну не все же без VCL пишут, верно ?
Вторая ситуация - как раз для VCL. Одна из изюминок VCL, в которой еще и окно модальное закрыть невозможно по похожим причинам в данном случае.

white_niggerПоток сознания какой-то, всё в кучу сгрёб...
Понятно. К счастью, я не пользуюсь твоими библиотеками.

white_niggerPS: Можно и детородный орган сломать если не понимаешь что делаешь
Похоже, ты не понимаешь, что делаешь, раз пользуешься таким. (если не пользуешься - зачем советовать другим тогда - вредительство одно)

schi,

В этом случае нет, потому-что цикл, запускаемый при показе VCL-ного модального окна, обрабатывает Idle, который вызывает Synchronize.
Но никто не застрахован от не-VCL-ных циклов обработки сообщений.

Я о другом говорил. Если есть открытое модальное окно (VCL-ное), и при этом запустить свой цикл GetMessage/WaitMessage/MsgWaitForMultiplyObjects, то закрыть это окно будет невозможно (оно закроется только при окончании этого цикла).

schi,

А, кстати, если вызвать VCL-ное модальное окно из dll (наверно даже из bpl), то тогда тоже никакие Synchronize не выполнятся. Будут висеть, пока не закроется модальное окно)) Т.к. список Synchronize-функций для выполнения в оконной процедуре в dll пустой))

schiКак бы модальное оно на то и модальное, чтобы своих циклов не запускать.
Он может быть запущен в любом месте программы, при любом событии. Главное - чтоб из цикла, запущенного при открытии этого "модального" окна (а так и будет, когда оно открыто и является верхним).
schiНо причем тут Лужков Syncronize ? :)
Похожая проблема. А еще 20861970

schiИз BPL вряд ли. А с DLL довольно много хитростей и без межмодульных вызовов, потому что глобальные переменные начинают размножаться.
Про bpl я не утверждаю - не знаю, как там всё работает.
А в dll я хитростей не вижу. Глобальные переменные те же. Ну, некоторые разные, конечно, типа Application.MainForm, но я ж не пользуюсь таким)

white_niggerРазные они, разные...
Их значения разные. Не всегда. И так и должно быть. Что в этом неудобного - не знаю.

schi, ну понятно, что полностью одинаковые у них только названия)
Но и значения у многих тоже. Например, CurrencyStr, версия ОС и т.д.

white_niggerYuRockИх значения разные. Не всегда. И так и должно быть. Что в этом неудобного - не знаю.Крут! А а не в курсе, что у кучи народа масса проблем с этим, особенно в части VCL?Откуда же мне это знать.
У кучи людей и с Synchronize проблем масса, и вообще с VCL, да и вообще с компьютерами.