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

Question

Отказ от ответственности: Я не знаком с API Win32, особенно с тем, как работают окна.

Я хотел бы сделать окно какого-либо процесса дочерним окном другого процесса. Эти два процесса также являются родительскими и дочерними. Но я не думаю, что это важно. Пока все работает как шарм - пока я не замораживаю основной поток дочернего окна.

Представьте себе, что container.exe notepad.exe 'хозяев и someApplication.exe

Когда я приостановить основную нить someApplication.exe в течение нескольких секунд, его окно заморожен на эту сумму времени. Это совершенно понятно. Но окно container.exe будет также висит за то же время. Детские окна других размещенных процессов (например, notepad.exe) будут продолжать работать нормально.

Я использую команду SetParent, чтобы сделать обычное окно без ДЕТСКОГО ребенка моего container.exe:

SetParent(
    childProcess.HWND, 
    myOwnHWND 
); 

После этого, я использую setWindowPos:

SetWindowPos(
    childProcess.HWND, 
    HWND_TOP, 
    someXPos, 
    someYPos, 
    0, 
    0, 
    SWP_FRAMECHANGED or SWP_NOSIZE or SWP_SHOWWINDOW 
) 

As MSDN article on SetParent предлагает, я также очищаю атрибут стиля WS_POPUP и добавляю атрибут WS_CHILD. Так как это тоже не помогло, я также добавил атрибут расширенного стиля WS_EX_NOACTIVATE, используя команду SetWindowLongPtr. Наконец, я попытался отправить оба окна WM_UPDATEUISTATE, а затем сообщение WM_CHANGEUISTATE, но это также не изменило ничего.

Что меня смущает, так это то, что окно родительского процесса продолжает рисоваться нормально, пока я не коснусь его. Затем он полностью замораживается, пока дочернее окно не размораживается. Я подозреваю, что что-то называется 'входной очереди'. MSDN article около WM_ACTIVATE сообщений гласят:

Направлена ​​как окно активируется и деактивируется окно. Если в окнах используется одна и та же входная очередь, то сообщение отправляется синхронно, сначала к оконной процедуре деактивируется окно верхнего уровня, а затем к оконной процедуре активированного окна верхнего уровня. Если окна используют разные входные очереди, сообщение отправляется асинхронно, поэтому окно активируется немедленно.

Из-за этого я возлагал большие надежды на атрибут расширенного стиля WS_EX_NOACTIVATE.

Подводя итог: на самом деле возможно разместить окно другого процесса и не замораживать собственное окно, когда дочернее окно зависает?

Answer 1

Вы не можете ожидать блокировки нити GUI любого процесса. В вашем сценарии ситуация немного сложнее, потому что есть два потока графического интерфейса. Один для каждого процесса.

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

Windows, которые находятся в отношениях родителя/ребенка, отправят друг другу сообщения. И если эти сообщения синхронны, они отправляются, а не отправляются, то блокирование одного потока GUI приведет к блокировке другого.

Золотое правило программирования GUI остается в силе: не блокируйте нить GUI. Если у вас многолетняя задача, переместите ее на фоновый поток.

Update

ОК, как описано here, когда вы связываете окна из разных потоков прикреплении их очереди сообщений друг другу. И если вы блокируете один поток, вы блокируете все связанные потоки.

Итак, не блокируйте нить GUI.