Обнаружилась следующая проблема. Пишется dll-библиотека, подключаемая в МТ4 и выполняющая длительный расчет. На время расчета выводится диалоговое окно с кнопкой Прервать. Для того, чтобы кнопка работала, в процессе обсчета вызывается цикл:

                        MSG msg;
                        while (!fAbort && PeekMessage(&msg, NULL, 0, 0, TRUE))
                        if(!IsDialogMessage(hdlgAbort, &msg))
                        {
                            TranslateMessage(&msg);
                            DispatchMessage(&msg);
                        }

Как видно, обрабатываются только сообщения, относящиеся к выведенному окну, т.е. корректно.

Когда МТ4 в оффлайне все отлично. Когда МТ4 в онлайне, предположительно при приходе нового тика, все локальные переменные внутри start сбрасываются в начальные значения (напр. ноль), причем в start стоит защита от повторных входов:

int start()
{
  Print("start");
  static datetime LastTime;
  static bool Processing;
  if(LastTime == Time[0]) return(0);
  if(Processing) return(0);
  LastTime = Time[0];
  Processing = true;
  Print("Enter");
  ...
  Processing = false;
  Print("Exit");
  return(0);
}

Если верить принтам, то вход внутрь start происходит, но все остальное пропускается (Enter и Exit не выводятся).

Каким же образом чистятся локальные переменные?

Вопрос: кто и что должен поправить, чтобы вывести диалог из dll без указанных побочных эффектов?

Как выяснилось, всё работает ещё более странно, чем я предполагал.

В тот момент, когда приходит новый тик, прекращается выполнение MQL-оператора вызова метода внутри DLL, который выполняет длительный расчет (видимо из-за message pump). В результате, расчет внутри DLL продолжается в фоне, а скрипт благополучно дорабатывает до конца, как будто работа DLL уже завершена, и все скриптовые переменные для блокировки повторного входа в расчет сбрасываются.

При формировании нового бара, запускается второй экземпляр расчета в DLL. И так далее.

Хотелось бы все-таки услышать мнение разработчиков. Нет никаких причин не анализировать скриптовый стек вызовов при приходе новых сообщений. Это баг.