Об альтернативе Application.ProcessMessages для TWebBrowser и разрыве стека выполнения

  При использовании TWebBrowser существуют две неприятности, во-первых, это сам TWebBrowser =), а во-вторых, это Application.ProcessMessages, который необходимо выполнять чуть ли не на каждое действие (загрузить документ, сменить режим редактирования и т.п).
  Использование Application.ProcessMessages может вызывать неожиданные проблемы. Особенно это актуально, когда используются оконные windows сообщения для разрыва стека выполнения. Но нашелся способ, которое позволяет не выбирать все сообщения из очереди. На первый взгляд, решение даже работает, однако буду рекомендовать никогда его не использовать и всегда использовать Application.ProcessMessage и об этом ниже.
  Очевидно, что WebBrowser обрабатывает какие-то сообщения. Но поиск их казался гиблой идеей.   В действительности оказалось, что ни так все плохо. С помощью Window Detective было обнаружено, что в момент загрузки происходит подозрительная посылка сообщений окну с именем класса  'Internet Explorer_Hidden'. Решил проверить и выбрал из очереди оконных сообщений в момент загрузки документа сообщения предназначенные только этому окну. К моему удивлению - все заработало.

Сообщения получаемые окном IE

Вообщем вот заготовка кода:

TMyWebBrowser = class(TWebBrowser)
protected
    procedure WBProcessMessage;
    procedure InternalSetValue(const AValue: string);
public
    procedure SetValue(const AValue: string); // Входная точка в примера
    procedure WaitWB;  
end;  


function EnumWindowsToFindIEHiddenProc(AHandle: HWND; AParam:NativeInt): boolean; stdcall;

var
  IEHiddenHandle: Hwnd;

implementation

procedure TMyWebBrowser.SetValue(const AValue: string);
begin
  InternalSetValue(AValue); // выполняем каким либо способом присваивание разметки
  WaitWB; // Ждем завершение загрузки документа.
  FooFunction; //Какой то функционал для работы которого необходим полностью загруженные html документ.
end;

procedure TMyWebBrowser.WaitWB;
begin
  //Как то так обычно выглядит ожидание пока документ полностью не загрузиться
  while HTMLDocument2.readyState <> 'complete' do
  begin
    WBProcessMessage; // выбираем только нужные сообщения
    //Forms.Application.ProcessMessages; // выбираем все сообщения из очереди
  end;
end;


procedure TbtkHTMLEditor.WBProcessMessage;
var
  msg: Windows.tagMSG;
  processID : THandle;
begin
  IEHiddenHandle := 0;
  processID := GetCurrentProcessId;
  if EnumWindows(@EnumWindowsToFindIEHiddenProc, processID) then // �щем хендл окна IE в нашем процессе перебирая все окна
    if IEHiddenHandle <> 0 then // Проверяем найденный хендл валидный
      if PeekMessage(msg, IEHiddenHandle, 0, 0, PM_REMOVE) then // извлекаем из очереди оконных сообщений все сообщения для окна IEHiddenHandle
      begin
        Windows.DispatchMessage(msg); // Передаем извлеченные сообщения окну IE
      end;
end;

function EnumWindowsToFindIEHiddenProc(AHandle: HWND; AParam:NativeInt): boolean;
var
  processId: NativeInt;
  classbuf: array[0..255] of Char;
const
   IEWndClassName = 'Internet Explorer_Hidden';
begin
     result := true;
    if Windows.GetWindowThreadProcessId(AHandle,@processId) <> 0 then
    begin
      if AParam = processId then
      begin
          GetClassName(AHandle, classbuf, SizeOf(classbuf));
          if lstrcmp(@classbuf[0], @IEWndClassName[1]) = 0 then
          begin
            IEHiddenHandle := AHandle;
            result := false;
          end;
      end;
    end;
 
end;

  Код на скорую руку, проверялся с IE 9-10 в Windows 7-8. Но в данном случае я избегаю слова "решение", тут больше подходит - "грязный хак". На самом деле, если у вас есть проблема того, что внезапный ProcessMessages нарушает строгий порядок ваших вызовов, то проблема не в ProcessMessages. ProcessMessages это данность архитектуры Windows и VCL. Если посылаете оконное сообщение, то будьте готовы, что оно может быть извлечено раньше, чем вы предполагаете. Например, из окна посылаем себе же сообщение WM_Close. Сообщение извлекается вот таким неожиданным ProcessMessages еще до раскрутки стека выполнения, который вызвал посылку этого сообщения. В результате дальнейшая раскрутка стека выполнения пойдет по освобожденным объектам, так как на WM_Close будет убито родительское окно и все дети на нем.

  Подобные проблемы не решить изъятием вызовов ProcessMessages. Любой модальный диалог нарушит подобный не очень хитрый план. Для избегания подобной проблемы нужно использовать другие подходы. Мы, например, подобные проблемы решаем так называемыми контекстами асинхронного выполнения и подсистемой асинхронных команд. Говоря "асинхронные команды", я не подразумеваю много-поточное выполнение, а только разрыв стека выполнения. Что и происходит, когда посылаем в свой же поток оконное сообщение.

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

Таким образом, асинхронная команда - это объект, который посылается в очередь сообщений, сообщением  WM_AsyncCommand, где в качестве параметра указатель на объект. При извлечении сообщения WM_AsyncCommand из очереди сообщений, у объекта асинхронной команды вызывается обработчик, который и исполняет полезный код. Асинхронная команда принадлежит контексту. Контекст создается при запуске приложения. Если на момент извлечения асинхронной команды из очереди сообщений контекст заблокирован, тогда асинхронная команда перемещается в особый буфер команд, где дожидается разблокировки контекста.  Все что осталось, это заблокировать контекст на момент начала роста стека вызовов, в котором могут посылаться команды, имеющие возможность порушить стек выполнения:

Context.Lock;

try

    AnyUserAction;

finally

    context.Unlock;

end;

Выше я приводил пример с WM_Close. Для этого мы используем TFormCloseAsyncCommand = class(TAsyncCommand). Ко всему прочему, контексты могут быть вложенными, а команды имеют фьючеры для возможности их отмены. Но это явно не вопрос темы текущей статьи (если кому интересно, то могу накидать шаблон кода и варианты использования в отдельной статье).

Вернемся к "грязному обходному пути" и оставим в стороне вопрос о том, что ProcessMessages - данность и не является безусловным злом. И тем не менее выборочная диспетчеризация сообщений для класса "Internet Explorer_Hidden" -  сомнительный путь:

1. Данный вопрос никак не документирован. В MSDN мне попадался только код вида while (browser.IsBusy){System.Windows.Forms.Application.DoEvents();} .

2. "Решение" не проверялось на всех возможных версиях IE и Windows.

3. Нет гарантии, что мы обрабатываем все нужные сообщения.

4. В будущем архитектура WebBrowser может измениться и данный подход уже может  не работать.

5. Извлекая только определенные сообщения, мы можем нарушить порядок обработки сообщений