C ++ / MFC - Предотвращение зависания дочернего элемента управления (ActiveX) от заморозки всего пользовательского интерфейса? - PullRequest
1 голос
/ 12 мая 2011

В настоящее время я играю с элементом управления Microsoft ActiveX от Microsoft и заметил, что могу заморозить всю программу, загрузив веб-страницу, которая вылетает из-за встроенного IE. Вот я и подумал, есть ли способ предотвратить зависание всей программы?

Я уже пробовал: - Создать новый CWinThread, создав / обработав Control -> Тот же результат - Создать новый диалог из этой темы, создав / обработав элемент управления -> Тот же результат

Проблема, кажется, глубоко в системе сообщений, но я не уверен.

Может кто-нибудь сказать мне, возможно ли вообще предотвратить зависание всего пользовательского интерфейса / диалога и что вызывает эту проблему?

(я уже искал в Интернете, но не нашел реального решения)

Спасибо, Гэри

PS: Единственный способ, который в настоящее время работает для меня, - это создать новый дочерний процесс, загружающий / обрабатывающий элемент управления. Я могу изменить его так, чтобы оно выглядело как дочернее окно моего главного диалога, но у меня есть возможность доступа к элементу управления непосредственно из кода моего главного диалога.

EDIT:

Хорошо, я нашел решение, которое меня устраивает. Я создаю окно заполнителя в главном приложении и запускаю новый дочерний процесс, содержащий фактический элемент управления. Я делегирую все перемещение окна / размер / и т.д. сообщения дочернему процессу, чтобы он мог перемещать / реагировать. Было важно не создавать новый процесс как объект WS_CHILD из моего основного приложения, потому что таким образом он все равно его замораживает. Я делюсь информацией через карту памяти с процессом и общаюсь, используя пользовательские сообщения. Я надеялся, что будет проще ...

1 Ответ

0 голосов
/ 15 мая 2011

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

Вы выбрали хорошую отправную точку (разделите фрейм в новый процесс). Что-то еще, о чем вы захотите узнать, это очереди ввода потоков и AttachThreadInput (http://msdn.microsoft.com/en-us/library/ms681956(VS.85).aspx). У Рэймонда тоже есть кое-что по этому поводу; в том числе часть разговора PDC http://blogs.msdn.com/b/oldnewthing/archive/2008/08/01/8795860.aspx.

Дополнительный совет: альтернативой здесь может быть просто запретить загрузку элементов управления AX в элемент управления вашего браузера, если они вам не нужны. И если они вам нужны и выстраивают очень общую замену браузера, вы должны ожидать много работы, чтобы повторить стабильность, которую вы найдете в основных браузерах.

...