Hungry Mind

Spartacus: Vengeance

2012-01-28T18:38:00.001+02:00

Начался новый сезон Spartacus: Vengeance.

Был в IMAX-е на Underworld: Awakening. Отличный экшн с кучей кровищи, поломанных костей, расчлененки и прочих радостей кинематографа. И минимум соплей.

Why not Android

2012-01-25T18:55:00.001+02:00

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

Не, ну, если смотреть как быстро производители клепают свои поделки, то через полтора года нужно думать не об поддержке системы, а о покупке нового девайса.

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

В соседней вселенной можно взять телефон в 2009-м году и получить обновление операционки нового поколения в декабре 2011-го. День-в-день с современнейшими моделями.
Причем user-experience (нет такого термина в русском, извините) очень тщательно сохраняется между моделями, юзеры заметно довольней чем у конкурентов.

Ковровое бомбометание моделями по всем существующим и выдуманным рыночным нишам говорит только об неуверенности производителя. Об отсутствии видения.

Зоопарк планшетов с шагом экрана в 1 дюйм - ярчайший пример. Фееричное растрачивание усилий по всем направлениям, а в результате - вышел киндл файр и слил весь зоопарк с первого места из догоняющих.

http://forum.ixbt.com/topic.cgi?id=16:42549-125#3872

Тупой писюн за рулем

2012-01-23T14:10:00.002+02:00

What a Shame

2012-01-18T17:39:00.001+02:00

Эталон колхозника за рулем

2012-01-13T13:54:00.000+02:00

Эталон тупого колхозника на дороге. Целый букет - просачивание рядом для выезда за стоп линию, наезд на пешеходный переход и проезд перекрестка на красный. Чтобы... поехать на мойку.

За рулем, видимо, водила, депутата внутри не было.

Android developers

2012-01-12T00:39:00.001+02:00

Diana Hackborn, единственная мать ОС Android. Теперь от этой ОС и телефонов на ее основе я буду держаться еще дальше. Гы.

DOTA 2 beta key

2012-01-08T20:55:00.000+02:00

Получил от добрых людей DOTA 2 beta gift. Блеять, оторваться не могу.

Интерфейс у игры конченный, сервера нестабильны. Бета - она и есть бета. Но кайфу от командной резни полные трусы.

Если у вас есть приглашения - с удовольствием передам их товарищам, которые любят и хотят играть в DOTA 2. Не хватает 3 человека в команду. Напишите, пожалуйста, если хотите поделиться.

Эталон ТП за рулем

2011-12-31T19:33:00.002+02:00

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

Cruel InvokeRequired

2011-12-23T13:16:00.000+02:00

Всем давно известно, что в WinForms начиная с версии 2 появилась защита от многопоточного использования элементов управления. При попытке выполнить опасные операции библиотечный код выбрасывает InvalidOperationException с текстом Cross-thread operation not valid: Control 'xxx' accessed from a thread other than the thread it was created on. Дальше я объясню как выполняется эта проверка и о некоторых подводных камнях этого механизма.

Свойство Handle класса Control имеет нетривиальную логику, часть которой содержит проверку на безопасность использования даного кода из другого потока:

[
Browsable(false), 
DesignerSerializationVisibility(DesignerSerializationVisibility.Hidden),
DispId(NativeMethods.ActiveX.DISPID_HWND), 
SRDescription(SR.ControlHandleDescr) 
]
public IntPtr Handle { 
   get {
       if (checkForIllegalCrossThreadCalls &&
           !inCrossThreadSafeCall &&
           InvokeRequired) { 
           throw new InvalidOperationException(SR.GetString(SR.IllegalCrossThreadCall,
                                                            Name)); 
       } 

       if (!IsHandleCreated) 
       {
           CreateHandle();
       }

       return HandleInternal;
   } 
}

Основная часть условия - свойство InvokeRequired:

[
Browsable(false), EditorBrowsable(EditorBrowsableState.Advanced), 
DesignerSerializationVisibility(DesignerSerializationVisibility.Hidden), 
SRDescription(SR.ControlInvokeRequiredDescr)
] 
public bool InvokeRequired {
   get {

       using (new MultithreadSafeCallScope()) 
       {
           HandleRef hwnd; 
           if (IsHandleCreated) { 
               hwnd = new HandleRef(this, Handle);
           } 
           else {
               Control marshalingControl = FindMarshalingControl();

               if (!marshalingControl.IsHandleCreated) { 
                   return false;
               } 

               hwnd = new HandleRef(marshalingControl, marshalingControl.Handle);
           } 

           int pid;
           int hwndThread = SafeNativeMethods.GetWindowThreadProcessId(hwnd, out pid);
           int currentThread = SafeNativeMethods.GetCurrentThreadId(); 
           return(hwndThread != currentThread);
       } 
   } 
}

Что здесь происходит? В локальную переменную hwnd записывается дескриптор текущего окна (если оно создано), иначе - дескриптор первого созданного окна в иерархии child-parent (метод FindMarshalingControl). Если ни один родитель не создан (нет дескриптора), метод InvokeRequired возвращает false. Далее используются функции GetWindowThreadProcessId и GetCurrentThreadId чтобы определить принадлежность созданного окна текущему потому. ОС Windows запоминает идентификаторы потоков в контексте которых произошли вызовы CreateWindow для создания окон.

Из этого можно сделать следующие выводы:

WinForms не изобретает колесо - лишь использует доступную информация для выполнения нужных проверок
Если окно не было создано (нет дексриптора), а также не были созданы все его родители - InvokeRequired возвращает false, что весьма логично - объект CLR может быть создан в любом потоке, но получит привязку к конкретному потоку лишь после создания

В результате следующий код содержит потенциальную проблему:

void handleNotificationFromOtherThread(...)
{
   if (someControl.InvokeRequired)
   {
      someControl.BeginInvoke(handleNotificationFromOtherThread, ...);
   }
   // Thread safe code here
   ...
}

Если уведомления прийдут до того, как хоть одно окно из иерархии будет создано, InvokeRequired вернет false и код выполнится в неправильном контексте. И здесь даже механизм защиты WinForms не поможет. В результате получаем многопоточный доступ к ресурсам без блокировок.

Как избежать подобного сценария? Создавая окно специально для целей синхронизации доступа:

Control sync = new Control();
sync.CreateControl();
_syncInvoke = (ISynchronizeInvoke)sync;

...

void handleNotificationFromOtherThread(...)
{
   if (_syncInvoke.InvokeRequired)
   {
      _syncInvoke.BeginInvoke(handleNotificationFromOtherThread, ...);
   }
   // Thread safe code here
   ...
}

Код выше принудительно создает окно в нужном контексте и использует его интерфейс ISynchronizeInvoke.

Но есть и более изящное решение - сохранить System.Threading.SynchronizationContext.Current как член класса и использовать для синхронизации. WinForms сам создаст по одному окну специально для маршаллинга вызовов в каждом потоке. Этот подход лучше всего подходит для простых сценариев, когда нужно отмаршаллить все выховы в один главный поток.

iPhone 4s jailbreak

2011-12-20T23:28:00.000+02:00

Пока что я жмотюсь платить по 10+$ за нужные мне программы. Это не долбанные игрушки по 99 центов, а необходимые в жизни вещи типа Wallet и iGO. Ну, просто психологически не готов вывалить даже 10 у.е. за программу, которая просто хранит текст в шифрованном виде. А 100 у.е. за навигацию - перебор. Но мучения мои скоро закончатся, грядет A5 jailbreak.

iPhone 4s case

2011-12-20T20:49:00.001+02:00

Решил, что чехол для роботизированной сучки нужен. Прошлый телефон изрядно пострадал из-за моего обращения с ним. Бросал в рюкзак, карманы, где ключи лежали и прочая чепуха. В результате на экране куча царапин и все такое. Бамперы и прочие подобные вещи считаю жлобством, поэтому выбор пал на мешочек (pouch по-буржуйски). Выбор пал на Sena SARACH ULTRASLIM White-Red.

Стоимость там - 40$. У нас - 60$. Заказал, привезли. На радостях отдал деньги курьеру, а лишь после заметил, что швы с одной стороны сильно перетянуты и в результате два слоя кожи не состыкованы, а слеплены. Ну, похоже на результат удара двух тектонических плит.

На упаковке - made in Turkey. Сука, как это все надоело! Кусок кожи стоимостью 60 у.е. сшит тяп-ляп в Турции. Вовремя позвонил курьеру и забрал обратно деньги, заебали.

Вывод? Просить чтобы привозили несколько экземпляров на выбор или не покупать вещи по маразматичным ценам.

iPhone 4s and SIRI

2011-12-18T16:46:00.001+02:00

Получил я наконец свой iPhone 4S White 32Gb. Первое впечатление - говно. Но после пары часов использования, подключения к iCould и пр. - я понял, что сделано для людей. Очень удобный телефон.

На фотках белый выглядит гораздо лучше, чем в жизни. Черный на мой вкус смотрится более шикарно. Наверное из-за отражающего эффекта покрытия.
SIRI требует подключение к интернету и жрет трафик. Падла отсылает сжатый звук на сервер Apple, где происходит его анализ и генерация результатов. Транслитерацию не поддерживает, поэтому контакты должны использовать английский алфавит. С СМС-ками та же проблема.
После подключения симки происходило 2-3 пропадания сети Киевстар, что заставило злиться и спровоцировало поток матов. Симка то испорчена. Но после все образовалось. Не знаю почему. Возможно из-за отключения авто поиска сети и установки свежей прошивки. Перед этим я начитался о множестве проблем с пропаданием сети оператора Киевстар.
Батарею не сжирает. За ночь простоя ушло 3%. Если не пользоваться активно (как задрот или жлоб в метро)- жить будет 3-4 дня, полагаю. Геолокационные сервисы включены ВСЕ.
Камера понравилась. Хоть и сравнить не с чем, я никогда не пользовался телефоном как фотоаппаратом.
Работает шустро, тормоза не замечены нигде.

.NET Framework 4 Platform Update 2

2011-12-07T23:33:00.001+02:00

А вы в курсе, что появился уже .NET Framework 4 Platform Update 2? Многие, наверное, не знают даже, что уже полгода как у многих установлен .NET Framework 4 Platform Update 1.

"Unsupported" C++ namespace names

2011-12-03T13:51:00.001+02:00

Замечали такие вот интересные идентификаторы пространств имен: Win32Hosts.dll!<CrtImplementationDetails>::LanguageSupport::Initialize()? А вот как это делается:

namespace __identifier("<CrtImplementationDetails>")
{
...
}

Unable to step into .NET v4.0.30319 source

2011-11-09T15:11:00.000+02:00

У меня длительное время пункт меню Go To Source Code недоступен, отлаживать исходный код .NET Framework невозможно. В окне Modules почти все сборки имеют Symbol Status = Symbols loaded. Проблема лишь в том, что pdb файлы маленького размера, а это значит, что информации об исходном коде в них нет.

Ответ нашелся в разделе Reference Source Server Discussion.

Решение состоит в использовании следующих версий сборок:

Name	Version
mscorlib.dll	4.0.30319.1 (RTMRel.030319-0100)
PresentationFramework.dll	4.0.30319.1
WindowsBase.dll	4.0.30319.1 built by: RTMRel

Поэтому нужен .NET Framework 4 RTM, без патчей, которые накатывает операционная система. Следующие версии сборок не имеют соответствий в базе pdb файлов хранилища Reference Source:

Name	Version
mscorlib.dll	4.0.30319.488 (RTMLDR.030319-4800)
PresentationFramework.dll	4.0.30319.450
WindowsBase.dll	4.0.30319.450 built by: RTMLDR

iPhone 4S around the world

2011-11-09T12:46:00.000+02:00

Китайцы наконец собрали мой iPhone 4S 32Gb White и отдали в службу доставки. Теперь он отправится в Торонто, затем в Нью-Йорк, а уж после приедет в Киев :-).

Location	Date	Local Time	Activity
Concord, ON, Canada	11/14/2011	18:45	Delivered
	11/14/2011	16:11	The customer was not available on the 1st attempt. A 2nd delivery attempt will be made
	11/14/2011	7:55	Out for Delivery
	11/14/2011	5:49	Arrival Scan
Mount Hope, ON, Canada	11/14/2011	4:50	Departure Scan
Buffalo, NY, United States	11/13/2011	23:33	Departure Scan
	11/13/2011	23:32	Arrival Scan
Mount Hope, ON, Canada	11/13/2011	10:07	Arrival Scan
Louisville, KY, United States	11/12/2011	11:25	Departure Scan
Anchorage, AK, United States	11/11/2011	4:56	Arrival Scan
Chek Lap Kok, Hong Kong	11/11/2011	12:59	Departure Scan
Chek Lap Kok, Hong Kong	11/09/2011	16:30	Arrival Scan
Shenzhen, China	11/09/2011	15:15	Departure Scan
	11/09/2011	13:30	Origin Scan
China	11/09/2011	0:15	Order Processed: Ready for UPS

Oakley Polarized Juliet

2011-10-25T17:08:00.001+03:00

Заказал себе Oakley Polarized Juliet. 400$ в США, без примерки, естественно. Я идиот?

Вот так нужно с тупыми бабами за рулем!

2011-10-16T21:38:00.001+03:00

ICU quick starter

2011-10-11T00:09:00.000+03:00

Часто бывает необходимо выполнить преобразование текста из одной кодировки в другую. Скажем, отослать на HTTP сервер строку в Windows-1251, а после декодировать ответ.

WinAPI как всегда выручает - функции MultiByteToWideChar и WideCharToMultiByte делают преобразование из UTF-16 в необходимую кодировку и обратно. Список поддерживаемых кодовых страниц велик, но нет механизма для получения идентификатора кодировки по имени. Поэтому я задался целью найти альтернативу этим функциям. И я ее нашел - библиотека ICU. Есть еще iconv, но меня она оттолкнула всей этой гнушной чепухой, не захотелось даже возиться. А вот ICU вполне прилежно поставляется с проектными файлами для свежайшей версии Visual Studio.

Собрать ICU проще простого:

Скачиваем архив с исходными кодами со странички проекта, под колонкой ICU4C;
Разворачиваем содержимое и открываем source\allinone\allinone.sln;
Собираем обе конфигурации - Debug и Release;
Запускаем bin\icuinfo.exe, проверяем, что ICU Initialization returned: U_ZERO_ERROR;
Файл bin\icudtXY.dll должен быть внушительного размера - около 20 мегабайт.
В случае получения ошибок U_FILE_ACCESS_ERROR или U_MISSING_RESOURCE_ERROR - проверяем размер файла. Если слишком маленький - пересобираем проект makedata, у меня один раз случилось подобное, долго не мог понять в чем дело. Нашел на сайте следующее:

Why am I seeing a small ( only a few K ) instead of a large ( several megabytes ) data shared library (icudt)? Opening ICU services fails with U_MISSING_RESOURCE_ERROR and u_init() returns failure.

ICU libraries always must link with the ICU data library. However, so that ICU can bootstrap itself, it first builds a 'stub' data library, in icu\source\stubdata, so that the tools can function. You should only use this in production if you are NOT using DLL-mode data access, in which case you are accessing ICU data as individual files, as an archive (.dat) file, or some other means. Normally, you should be using the larger library built from icu\source\data. If you see this issue after ICU has completed building, re-run 'make' in icu\source\data, or the 'makedata' project in Visual Studio.

Размер bin\icudtXY.dll можно уменьшить с помощью ICU Data Library Customizer. Файл icudt48l.dat из скачанного архива необходимо раскрыть в папку source\data\in (а может и source\data\out, точно не помню) и пересобрать проект makedata.

Рассмотрим пример использования этой замечательной библиотеки. Попытаемся получить строку Приветик, ICU! в кодировке Windows 1251, затем обратно в UTF-16 и сравнить с оригиналом:

#include "stdafx.h"
 
#include <cassert>
 
#include <unicode/ucnv.h>
#include <unicode/ucsdet.h>
 
int _tmain(int argc, _TCHAR* argv[])
{
   const wchar_t * const sourceUTF16 = L"Приветик, ICU!";
   const size_t len = wcslen(sourceUTF16);
 
   UErrorCode uError(U_ZERO_ERROR);
 
   /////////////////////////////////////////////////////////////////////////////////////////////////////////////////////
   UConverter * const pConverter = ucnv_open("windows-1251", &uError);
   if (U_FAILURE(uError)) {
      return -1;
   }
 
   /////////////////////////////////////////////////////////////////////////////////////////////////////////////////////
   const char * const pszCharsetInternalName = ucnv_getName(pConverter, &uError);
   assert(U_SUCCESS(uError));
   assert(pszCharsetInternalName);
   const char * const pszCharsetIANAName = ucnv_getStandardName(pszCharsetInternalName, "IANA", &uError);
   assert(U_SUCCESS(uError));
   assert(pszCharsetIANAName);
 
   const size_t minCharSize = ucnv_getMinCharSize(pConverter);
   const size_t maxCharSize = ucnv_getMaxCharSize(pConverter);
 
   /////////////////////////////////////////////////////////////////////////////////////////////////////////////////////
   const wchar_t *pSourceW = &sourceUTF16[0];
   const wchar_t * const pSourceLimitW = &sourceUTF16[len];
   
   char *targetEncoding = reinterpret_cast<char *>(_alloca(maxCharSize * (len + 1)));
   char *pTarget = &targetEncoding[0];
   const char * const pTargetLimit = &targetEncoding[len];
   ucnv_fromUnicode(pConverter, &pTarget, pTargetLimit, &pSourceW, pSourceLimitW, NULL, true, &uError);
   assert(U_SUCCESS(uError));
   *pTarget = '\0';
 
   /////////////////////////////////////////////////////////////////////////////////////////////////////////////////////
   const char *pSource = &targetEncoding[0];
   const char * const pSourceLimit = &targetEncoding[len];
 
   wchar_t * const targetUTF16 = reinterpret_cast<wchar_t *>(_alloca(sizeof(wchar_t) * (len + 1)));
   wchar_t *pTargetW = &targetUTF16[0];
   const wchar_t * const pTargetLimitW = &targetUTF16[len];
   ucnv_toUnicode(pConverter, &pTargetW, pTargetLimitW, &pSource, pSourceLimit, NULL, true, &uError);
   assert(U_SUCCESS(uError));
   *pTargetW = L'\0';
 
   /////////////////////////////////////////////////////////////////////////////////////////////////////////////////////
   ucnv_close(pConverter);
 
   return 0;
}

Разберем по порядку:

Включение заголовочных файлов unicode/ucnv.h и unicode/ucsdet.h из папки include;
Открытие конвертера функцией ucnv_open.
В качестве параметра передаем имя кодовой страницы или ее аналог, один из многих альтернативных имен, поддерживаемых ICU.
В отладочных целях получаем внутреннее и стандартное имена открытого конвертера функциями ucnv_getName и ucnv_getStandardName;
Основная часть - аллокация памяти под результат и использование конвертера по назначению (функции ucnv_fromUnicode и ucnv_toUnicode);
Освобождение ресурсов, закрытие конвертера функцией ucnv_close.

Линкеру понадобятся icuuc.lib и icuin.lib для успешного создания исполняемого файла. А ему, в свою очередь, - библиотеки icuuc48.dll, icudt48.dll и icuin48.dll для успешного запуска.

В результате выполнения получаем следующий результат:

CEdit with an ellipsis

2011-09-01T12:56:00.000+03:00

Sometimes developers are devoted to absolutely rediculous tasks. Like having an established conception broken for some reason. You spend a lot of time cracking things up to acomplish your mission. Recently I was working on an edit control with an ellipsis if the text does not fit.

I came up with painting the edit in case it's not focused:

class CEllipsisEdit : public CEdit
{
   DECLARE_DYNAMIC(CEllipsisEdit)
 
protected:
   COLORREF GetBkColor() const;
 
protected:
   CBrush m_bkBrush;
 
protected:
   DECLARE_MESSAGE_MAP()
   afx_msg void OnPaint();
 
};

#include "EllipsisEdit.h"
 
IMPLEMENT_DYNAMIC(CEllipsisEdit, CEdit)
 
// CEllipsisEdit message map
 
BEGIN_MESSAGE_MAP(CEllipsisEdit, CEdit)
   ON_WM_PAINT()
END_MESSAGE_MAP()
 
// CEllipsisEdit message handlers
 
COLORREF CEllipsisEdit::GetBkColor() const
{
   if (m_hWnd) {
      const HWND hParentWnd = GetParent()->GetSafeHwnd();
      if (::GetWindowThreadProcessId(hParentWnd, NULL) == ::GetWindowThreadProcessId(m_hWnd, NULL)) {
         CDC dc;
         dc.CreateCompatibleDC(NULL);
         const bool enabled = (GetStyle() & WS_DISABLED) == 0;
         const UINT colorMsg = enabled ? WM_CTLCOLOREDIT : WM_CTLCOLORSTATIC;
 
         ::SendMessage(hParentWnd, colorMsg, reinterpret_cast<WPARAM>(dc.m_hDC), reinterpret_cast<LPARAM>(m_hWnd));
 
         return dc.GetBkColor();
      }
   }
 
   return ::GetSysColor(COLOR_WINDOW);
}
 
void CEllipsisEdit::OnPaint()
{
   if (::GetFocus() == m_hWnd) {
      __super::OnPaint();
      return;
   }
 
   CString text;
   GetWindowText(text);
 
   if (!m_bkBrush.m_hObject)
      m_bkBrush.CreateSolidBrush(GetBkColor());
   
   CPaintDC dc(this);
   
   RECT rc = { 0, 0, 0, 0 };   
   GetClientRect(&rc);
   dc.FillRect(&rc, &m_bkBrush);
   
   GetRect(&rc);
   dc.SetBkMode(TRANSPARENT);
   dc.SelectObject(GetFont());
   dc.DrawText(text, text.GetLength(), &rc, DT_SINGLELINE | DT_NOPREFIX | DT_WORD_ELLIPSIS);
}

There were several problems:

Edit control would paint itself synchronously. No WM_PAINT message is sent, just GetDC(hwnd) and the paint code, no way to sabstitute painting.
Edit control doesn't have non-client area, borders are drawn in client area.
Have to somehow determine text background color.

Synchronous paint seems to be an issue only with focused control. Borders are drawn as usual for unknown reason. Background color shall be determined by sending WM_CTLCOLOREDIT or WM_CTLCOLORSTATIC to parent or just a COLOR_WINDOW system color as a fallback.

Please note that WM_CTLCOLOR-related messages are not sent to parent widows in different threads! Also don't forget to add DT_NOPREFIX flag when invoking DrawText method.

Implementing popups in MFC (part 1)

2011-08-22T18:32:00.000+03:00

Создание всплывающих окон - задача не из легких. Особенно если это не банальная контекстная подсказка, а, скажем, окно с элементами управления или необходимостью пользовательского взаимодействия (мышь, клавиатура). Самый распостраненный случай всплывающего окна - Combo Box.

Великий и могучий Combo Box.

Combo Box - это сложный элемент управления, как правило состоящий из списка (List Box), поля ввода (Text Box) и несколько кастрированной кнопки (Button).

Особенности работы Combo Box:

При нажатии на кнопку (это не единственный способ) появляется выпадающий список
Это окно по своей сути является стандартным List Box-ом, но на стероидах (с именем класса ComboLBox)
Фокус ввода остается на самом Combo Box-е, всплывшее окно со списком не активируется
Выпадающее окно производит захват мыши вызовом SetCapture, в результате чего все мышиные сообщения для всех окон процесса попадают исключительно в оконную процедуру всплывшего окна
При щелчке мышью вне выпадающего окна - оно скрывается сразу же при обработке WM_?BUTTONDOWN, при этом захват мыши отменяется вызовом ReleaseCapture, что приводит к получению WM_?BUTTONUP окном, которое находилось под курсором в момент отжатия кнопки
При щелчке внутри выпадающего окна, оно реагирует закрытием во время обработки WM_?BUTTONUP
Список реагирует на нажатия стрелочных кнопок (вверх, вниз); очевидно, что сообщения WM_KEYDOWN приходят в сам Combo Box, а он их передает в выпадающий список
При потере Combo Box-ом фокуса ввода - список прячется

Важные выводы:

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

А если не Combo Box?

В ОС существует множество выпадающих окон кроме Combo Box. Среди них - Date and Time Picker, меню (стандартное меню ОС, навороченное меню типа Ribbon или другие реализации, например WPF) и множество других. И я вас уверяю - единой концепции взаимодействия с пользователем у них нет...

Стандартное меню, которое предоставляет операционная система, работает безотказно, но весьма ограничено в отображаемом контенте и функциональности. Я остановил процесс по таймеру во время трекинга меню функцией TrackPopupMenu. Эта функция блокирует выполнение программы и реализована ядром. Но при этом цикл сообщений крутится внутри нее, поэтому программа остается отзывчивой:

> Win32App.exe!CTopLevelWnd::OnTimer(unsigned int nIDEvent)  Line 211 C++
  Win32App.exe!CWnd::OnWndMsg(unsigned int message, unsigned int wParam, long lParam, long * pResult)  Line 2411 C++
  Win32App.exe!CWnd::WindowProc(unsigned int message, unsigned int wParam, long lParam)  Line 2087 + 0x20 bytes C++
  Win32App.exe!AfxCallWndProc(CWnd * pWnd, HWND__ * hWnd, unsigned int nMsg, unsigned int wParam, long lParam)  Line 257 + 0x1c bytes C++
  Win32App.exe!AfxWndProc(HWND__ * hWnd, unsigned int nMsg, unsigned int wParam, long lParam)  Line 420 C++
  user32.dll!_InternalCallWinProc@20()  + 0x23 bytes 
  user32.dll!_UserCallWinProcCheckWow@32()  + 0xb3 bytes 
  user32.dll!_DispatchClientMessage@20()  + 0x4b bytes 
  user32.dll!___fnDWORD@4()  + 0x24 bytes 
  ntdll.dll!_KiUserCallbackDispatcher@12()  + 0x2e bytes 
  user32.dll!_DispatchClientMessage@20()  
  user32.dll!_NtUserTrackPopupMenuEx@24()  + 0xc bytes 
  user32.dll!_TrackPopupMenu@28()  + 0x1b bytes 
  Win32App.exe!CMenu::TrackPopupMenu(unsigned int nFlags, int x, int y, CWnd * pWnd, const tagRECT * lpRect)  Line 1310 + 0x26 bytes C++

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

В отличии от Combo Box, контекстное меню ОС не съедает щелчок вне окна меню, но при этом так же не пропускает WM_MOUSEMOVE и WM_NCMOUSEMOVE.

А это реализация навороченного меню библиотекой Codejock Xtreme Toolkit Pro. WM_MOUSEMOVE и WM_NCMOUSEMOVE не блокируются, даже контекстная подсказка выскочила, что не очень то правильно. Точней они не блокируются для текущих контекстных окон (а их там два), блокируются для оставшихся тулбаров этой библиотеки (Ribbon в даном случае), а для остальных окон приложения (полоса прокрутки, область редактирования текста, бордера и пр.) - снова не блокируются.

Как и в случае с контекстным меню ОС, не съедает щелчек вне окон контекста.

Собственная реализация TrackPopupMenu устанавливает различные хуки для слежения за сообщениями, механизм SetCapture/ReleaseCapture здесь уже не при делах.

Кстати, прототип этой реализации - Microsoft Office 2007/2010, в котором WM_MOUSEMOVE блокируется для всех окон вне контекста, а WM_NCMOUSEMOVE работает слегка через жопу - при наведении на бордер окна курсор меняет свой внешний вид, кнопки минимизации, максимизации и закрытия окон прикидываются мертвыми, но если пошуршать курсором у правого-верхнего края окна, то крестик будет предательски нам подмигивать, выдавая ошибку в реализации этой задумки. Scenic Ribbon в, скажем, MS Paint имеет те же проблемы.

На этой картинке находится кусочек навороченного меню Visual Studio 2010, очевидно реализованного управляемым кодом. WM_MOUSEMOVE блокируется, а вот в случае WM_NCMOUSEMOVE все несколько сложнее. По моим наблюдениям не блокируется движение мышью по заголовку окна, кнопки минимизации, максимизации и закрытия окон реагируют на наведение подсветкой, но при этом контекстная подсказка не появляется (как это сделано - пока что загадка). При наведении на полосу прокрутки никакой реакции нет.

Как и в случае с контекстным меню ОС, не съедает щелчек вне окон контекста.

Я хочу отметить, что все эти менюшки - обыкновенные окна, ничего сверхестественного. И они никогда не активируются и не крадут фокус ввода. Истинные джентльмены.

Предательские реализации всплывающих контекстных окон

Контекстная подсказка этой кнопочки гордо сообщает нам о возможности Change your view. А при нажатии появляется якобы контекстное меню, которое почему-то приводит к деактивации главного окна Explorer. Взгляните на цвет заголовка, он ясно дает понять - окно более не активно. Предательское окно ворует фокус ввода, он находится на элементе управления типа Slider. Причем рамка фокуса изначально не отображается, лишь когда нажать клавиши стрелок (вверх или вниз).

При этом на блокировку WM_??MOUSEMOVE нет даже намека - все элементы управления реагируют на перемещение курсора, всплывают подсказки, причем под этим меню. А самое вкусное - WM_?BUTTONDOWN проглатывается, а последующий WM_?BUTTONUP проходит. Результат схлопывания меню зависит от реализации элемента управления, по которому был произведен щелчок, - ответная реакция на WM_?BUTTONDOWN или же на WM_?BUTTONUP.

Кстати, открыл для себя что градация слайдера имеет дискретную структуру с 4 шагами снизу (где разделители нарисованы) и непрерывную (с очень мелким шагом) в области, где разделителей нет. Иконки плавно меняют свой размер.

Весьма странная реализация, если сравнить с предыдущими.

Альтернативный подход

Открыв контекстное меню Firefox, вы убедитесь, что оно никак не влияет на остальные окна, что, впрочем, выглядит вполне логично. Щелчки обрабатываются как обычно, но перед этим меню пропадает с экрана.

С другой стороны, отсутствие реакции окон на движение мышью подсказывает пользователю, что где-то открыто контекстное меню или модальный диалог, но лишь потому, что ОС Windows работает подобным образом.

Реализация собственных контекстных меню

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

Реакция окон (этого же приложения) вне контекста на перемещение указателя мыши
Щелчки мышью по окнам (этого же приложения) вне контекста
Деактивация активного окна приложения

Отслеживание мыши

Для слежения за мышью есть такие подходы:

SetCapture/ReleaseCapture
С помощью этих функций можно произвести захват/освобождение мыши и направить все сообщения в оконную процедуру одного окна. Но именно с этим связана огромная проблема - мы же хотим отображать сложные окна с элементами управления, которые тоже должны получать мышиные сообщения. В результате обработчики WM_??MOUSE?? выпадающего окна должны будут сами обеспечивать попадание нужных сообщений в оконные процедуры дочерних окон. Нужных - хорошо написано, а на деле - всех возможных. Фактически мы будем эмулировать то, что делает сама ОС Windows. Может показаться, что достаточно лишь найти окно под курсором функцией WindowFromPoint и вызвать оконную процедуру найденного окна, но на самом деле нюансов огромное множество, как и эмулируемых сообщений.

Сам по себе этот сценарий не позволяет контролировать механизм проглатывания щелчков вне контекста. Допустим, при щелчке мы хотим спрятать выпадающее окно, а после этого получить реакцию на щелчок окном, по которому он был произведен. Из-за SetCapture сообщение WM_LBUTTONDOWN извлекается из очереди и попадает в оконную процедуру выпадающего окна, где код определяет положение курсора и прячет окно, если оно находилось вне его области. Далее нужно обеспечить обработку этого сообщения, для этого вызываем AfxCallWndProc (или просто SendMessage). И делаем мы это из обработчика WM_LBUTTONDOWN нашего выпадающего окна! А что если реакцией на щелчок будет повторное выпадение окна (возможно вовсе не этого)? Мы пополним стек потока на добрую дюжину вызовов. И вот здесь все зависит от цикла сообщений. Есть два варианта:
1. Показать окно и выйти из метода ShowPopup (неблокирующий вызов).
  Цикл сообщений при этом остается прежним (как он реализован в приложении), проблем со стеком здесь быть не должно, но это вносит свои трудности в удобство использования такого программного интерфейса - нельзя держать объекты на стеке (окна, контроллеры, политики и т.д.), при выходе из обработчика окно продолжает висеть на экране и следить за обстановкой, ожидая момента, когда можно спрятаться и уничтожить все следы своего сущевствования, уведомив владельца о произошедшем.
2. Показать окно и запустить свой цикл сообщений в методе ShowPopup (как это делает TrackPopupMenu, блокирующий вызов).
  В этом случае мы можем вызвать переполнение стека банальными щелчками мыши, которые постоянно приводят к пропаданию текущего выпадающего окна и появлению нового - метод ShowPopup будет вызываться рекурсивно, каждый раз запуская новый цикл сообщений. Это весомый аргумент против. А бороться с ним крайне сложно. Фактически нужно куда-то сохранить полученное сообщение, которое привело к закрытию выпадающего окна, и уведомить внешний цикл сообщений, что его нужно обработать. К сожалению MFC такой тонкой настройки не предоставляет, придется заменить его цикл сообщений своим (банально скопировав код MFC и добавив туда свое). Это уже как-то слишком сложно для поддержки выпадающих окон.
И последний, самый важный нюанс SetCapture: захват может производиться лишь одним окном и вложенность захвата не поддерживается. Это означает, что любой элемент управления, использующий функцию SetCapture, приведет к снятию установленного захвата и поломке выдающего окна. С подобным, вероятно, можно бороться, но это весьма затратно и совершенно не перспективно для исследования.

Очевидно, что этот путь обречен на хардфакинг и успешность его сомнительна, отбрасываем.
Перехватчики (hooks) WH_GETMESSAGE, WH_MOUSE и WH_MOUSE_LL
С их помощью можно следить за очередью сообщений, отлавливать интересные события. Перехватчики - единственный способ гарантированно получить доступ к содержимому очереди сообщений. Можно было написать свой цикл сообщений (вариант блокирующего вызова ShowPopup) и в промежутке между GetMessage и DispatchMessage выполнять анализ и предпринимать действия. Но есть одна проблема - циклы сообщений могут запускаться в результате реакций на действия пользователя. К примеру, если открыть Date and Time picker, - он запускал вложенный цикл сообщений в версиях ОС Windows до Vista, а также в версиях Common Controls до 6-й. Все это приводит к неконтролируемой потере управления над циклом сообщений и, как последствие, невозможности отлавливать интересующие события.

Перехватчики WH_GETMESSAGE и WH_MOUSE получают управление перед возвратом функциями GetMessage и PeekMessage управления в случае наличия сообщения в очереди (удовлетворяющего критериям). Однако WH_MOUSE позволяет выполнять лишь мониторинг сообщений, а WH_GETMESSAGE - модифицировать ко всему прочему. WH_MOUSE_LL в этом плане похож на своего собрата WH_MOUSE, но система дает ему управление перед тем, как поместить сообщение в очередь. Это дает возможность спрятать всплывающее окно прежде, чем цикл сообщений получит щелчок мышью, который к этому привел.

Стратегии реализации

Реализация набора классов, которые позволяют показывать всплывающие окна, зависит от следующих факторов:

Механизм работы метода ShowPopup - блокирующий или неблокирующий
Необходимость проглатывания сообщений, которые приводят к закрытию всплывающего окна
Фильтрация перемещений указателя мыши
Отсутствие привязки к библиотеке, с момощью которой окно было создано (MFC, ATL, ...) - возможность работы с окнами, передаваемыми по дескриптору (HWND)
Возможность предоставить некую политику функционирования, с помощью которой можно сделать тонкую настройку всего механизма и реализовать сложные сценарии

Я остановился на блокирующем ShowPopup, с внутренним циклом обработки сообщений и возможностью настройки поведения через политику. Интерфейс моего класса CPopupController выглядит следующим образом:

public:
   CPopupController(IPopupEnvironment *pEnvironment);
 
public:
   void ShowPopup(HWND hWnd, HWND hOwner, const POINT &ptAnchor, IPopupPolicy *pPopupPolicy = NULL);
   void DismissPopup();

Для начала разберемся в каких случаях всплывающее окно должно быть закрыто без привязки к его внутренностям (поведение меню):

Деактивация приложения (foreground thread больше не является потоком этого приложения)
Щелчки вне контекста
Уничтожение окна
Изменение состояний окна на такие, в которых режим меню смысла больше не имеет (окно invisible, disabled etc.)

Реализовать это поведение достаточно просто - привязаться к всплывающему окну и реагировать на сообщения, присылаемые ОС Windows. Для этого можно использовать класс CWindowSubclass:

BEGIN_MSG_MAP(CPopupController)
   MESSAGE_HANDLER(WM_ACTIVATE, OnActivate)
   MESSAGE_HANDLER(WM_ACTIVATEAPP, OnActivateApp)
   MESSAGE_HANDLER(WM_SHOWWINDOW, OnShowWindow)
   MESSAGE_HANDLER(WM_ENABLE, OnEnable)
   MESSAGE_HANDLER(WM_SYSCOMMAND, OnSysCommand)
   MESSAGE_HANDLER(WM_MOUSEACTIVATE, OnMouseActivate)
   MESSAGE_HANDLER(WM_DESTROY, OnDestroy)
END_MSG_MAP()

LRESULT CPopupController::OnActivate(UINT uMsg, WPARAM wParam, LPARAM lParam, BOOL &bHandled)
{
   UNREFERENCED_PARAMETER(uMsg);
   UNREFERENCED_PARAMETER(lParam);
 
   if (wParam == WA_INACTIVE) {
      if (IPopupPolicy * const pPopupPolicy = GetPopupPolicy()) {
         if (pPopupPolicy->DismissPopupOnLosingActivation()) {
            DismissPopup();
         }
      }
      else
         DismissPopup();
   }
   bHandled = FALSE;
   return 0;
}
 
LRESULT CPopupController::OnActivateApp(UINT uMsg, WPARAM wParam, LPARAM lParam, BOOL &bHandled)
{
   UNREFERENCED_PARAMETER(uMsg);
   UNREFERENCED_PARAMETER(lParam);
 
   if (wParam == FALSE) {
      DismissPopup();
   }
 
   bHandled = FALSE;
   return 0;
}
 
LRESULT CPopupController::OnShowWindow(UINT uMsg, WPARAM wParam, LPARAM lParam, BOOL &bHandled)
{
   UNREFERENCED_PARAMETER(uMsg);
   UNREFERENCED_PARAMETER(lParam);
 
   if (wParam == FALSE) {
      DismissPopup();
   }
 
   bHandled = FALSE;
   return 0;
}
 
LRESULT CPopupController::OnEnable(UINT uMsg, WPARAM wParam, LPARAM lParam, BOOL &bHandled)
{
   UNREFERENCED_PARAMETER(uMsg);
   UNREFERENCED_PARAMETER(lParam);
 
   if (wParam == FALSE) {
      DismissPopup();
   }
 
   bHandled = FALSE;
   return 0;
}
 
LRESULT CPopupController::OnSysCommand(UINT uMsg, WPARAM wParam, LPARAM lParam, BOOL &bHandled)
{
   UNREFERENCED_PARAMETER(uMsg);
   UNREFERENCED_PARAMETER(lParam);
   
   if (wParam == SC_CLOSE) {
      DismissPopup();
   }
   
   bHandled = FALSE;
   return 0;
}
 
LRESULT CPopupController::OnMouseActivate(UINT uMsg, WPARAM wParam, LPARAM lParam, BOOL &bHandled)
{
   UNREFERENCED_PARAMETER(uMsg);
   UNREFERENCED_PARAMETER(wParam);
   UNREFERENCED_PARAMETER(lParam);
 
   if (m_pPopupPolicy) {
      const IPopupPolicy::eMouseActivateResult maResult = m_pPopupPolicy->MouseActivateAction();
      if (maResult != IPopupPolicy::eDefaultMouseActivateAction) {
         return maResult;
      }
   }
 
   bHandled = FALSE;
   return 0;
}
 
LRESULT CPopupController::OnDestroy(UINT uMsg, WPARAM wParam, LPARAM lParam, BOOL &bHandled)
{
   UNREFERENCED_PARAMETER(uMsg);
   UNREFERENCED_PARAMETER(wParam);
   UNREFERENCED_PARAMETER(lParam);
   
   ContinueMessageLoop(false);
 
   bHandled = FALSE;
   return 0;
}

Суть обработчиков - словить условия закрытия окна и, собственно, закрыть, выполнив все необходимые очистки. Исключение составляет обработчик WM_DESTROY - здесь мы просто устанавливаем флаг, который заставит завершить цикл сообщений.

Если вдруг код приложения по какой-то причине спрячет окно, уничтожит его, или же поменяет его состояние на disabled, - контроллер автоматически выполнит закрытие режима меню.

Следующий шаг - игра в кошки-мышки. Будем гоняться за мышью и лапкой (точней рукой сурового программиста) давать ей по носу. Для этого нам необходим перехватчик сообщений WH_GETMESSAGE. Здесь в игру вступает класс CPopupManager:

bool EnterPopupMode(CPopupController *pController);
bool IsPopupMode() const;
void ExitPopupMode(CPopupController *pController);

Задача этого класса - быть связующим звеном между контроллером выпадающего окна и ОС. В числе прочего - устанавливать необходимые перехватчики и передавать управление контроллеру. По-сути, это менеджер контроллеров, общий для UI потока (в случае многопоточного UI все гораздо сложней, но решаемо благодаря таким людям, как Я).

Полная версия менеджера выглядит следующим образом:

#pragma once
 
class CPopupController;
 
class CPopupManager : public CNoTrackObject
{
 
public:
   CPopupManager();
 
   static CPopupManager &Instance();
 
   bool EnterPopupMode(CPopupController *pController);
   bool IsPopupMode() const;
   void ExitPopupMode(CPopupController *pController);
 
private:
   static LRESULT CALLBACK GetMsgProc(int nCode, WPARAM wParam, LPARAM lParam);
   static LRESULT CALLBACK CBTProc(int nCode, WPARAM wParam, LPARAM lParam);
   
   bool PreFilterMessage(LPMSG pMsg, bool preview);
   bool ActivatingWindow(HWND hWnd, LPCBTACTIVATESTRUCT pCBAS);
   bool SettingFocus(HWND hSetFocusWnd, HWND hKillFocusWnd);
 
private:
   CPopupController *m_pController;
   HHOOK m_hGetMessageHook;
   HHOOK m_hCBTHook;
 
};

#include "stdafx.h"
#include "PopupManager.h"
#include "PopupController.h"
#include "PopupPolicy.h"
 
CProcessLocal<CPopupManager> afxPopupManager;
 
CPopupManager::CPopupManager() : m_pController(NULL), m_hGetMessageHook(NULL), m_hCBTHook(NULL)
{
}
 
CPopupManager &CPopupManager::Instance()
{
   return(*afxPopupManager);
}
 
bool CPopupManager::EnterPopupMode(CPopupController *pController)
{
   ATLASSERT(pController && !IsPopupMode());
   if (!pController || IsPopupMode())
      return false;
 
   m_hGetMessageHook = ::SetWindowsHookEx(WH_GETMESSAGE, &CPopupManager::GetMsgProc, NULL, ::GetCurrentThreadId());
   ATLASSERT(m_hGetMessageHook);
 
   if (pController->GetPopupPolicy()) {
      m_hCBTHook = ::SetWindowsHookEx(WH_CBT, &CPopupManager::CBTProc, NULL, ::GetCurrentThreadId());
      ATLASSERT(m_hCBTHook);
   }
 
   m_pController = pController;
 
   return true;
}
 
bool CPopupManager::IsPopupMode() const
{
   return m_pController != NULL;
}
 
void CPopupManager::ExitPopupMode(CPopupController *pController)
{
   ATLASSERT(IsPopupMode());
   ATLASSERT(m_pController == pController);
 
   m_pController = NULL;
 
   if (m_hCBTHook) {
      ATLVERIFY(::UnhookWindowsHookEx(m_hCBTHook));
      m_hCBTHook = NULL;
   }
 
   if (m_hGetMessageHook) {
      ATLVERIFY(::UnhookWindowsHookEx(m_hGetMessageHook));
      m_hGetMessageHook = NULL;
   }     
}
 
LRESULT CPopupManager::GetMsgProc(int nCode, WPARAM wParam, LPARAM lParam)
{
   if (nCode < 0) {
      return(::CallNextHookEx(NULL, nCode, wParam, lParam));
   }
 
   if (nCode == HC_ACTION) {
      LPMSG const pMsg = reinterpret_cast<LPMSG>(lParam);
      if (WM_MOUSEFIRST <= pMsg->message && pMsg->message <= WM_MOUSELAST
          || WM_NCMOUSEMOVE <= pMsg->message && pMsg->message <= WM_NCXBUTTONDBLCLK
          || WM_KEYFIRST <= pMsg->message && pMsg->message <= WM_KEYLAST) {
         if (Instance().PreFilterMessage(pMsg, wParam == PM_NOREMOVE)) {
            return 0;
         }
      }
   }
 
   return(::CallNextHookEx(NULL, nCode, wParam, lParam));
}
 
LRESULT CPopupManager::CBTProc(int nCode, WPARAM wParam, LPARAM lParam)
{
   if (nCode < 0) {
      return(::CallNextHookEx(NULL, nCode, wParam, lParam));
   }
 
   if (nCode == HCBT_ACTIVATE) {
      // The system is about to activate a window.
      if (Instance().ActivatingWindow(reinterpret_cast<HWND>(wParam), reinterpret_cast<LPCBTACTIVATESTRUCT>(lParam))) {
         return 0;
      }
   }
   else if (nCode == HCBT_SETFOCUS) {
      // A window is about to receive the keyboard focus.
      if (Instance().SettingFocus(reinterpret_cast<HWND>(wParam), reinterpret_cast<HWND>(lParam))) {
         return 0;
      }
   }
 
   return(::CallNextHookEx(NULL, nCode, wParam, lParam));
}
 
bool CPopupManager::PreFilterMessage(LPMSG pMsg, bool preview)
{
   ATLASSERT(m_pController);
   if (m_pController)
      return m_pController->PreFilterMessage(pMsg, preview);
   return false;
}
 
bool CPopupManager::ActivatingWindow(HWND hWnd, LPCBTACTIVATESTRUCT pCBAS)
{
   ATLASSERT(m_pController);
   if (m_pController)
      return m_pController->ActivatingWindow(hWnd, pCBAS);
   return false;
}
 
bool CPopupManager::SettingFocus(HWND hSetFocusWnd, HWND hKillFocusWnd)
{
   ATLASSERT(m_pController);
   if (m_pController)
      return m_pController->SettingFocus(hSetFocusWnd, hKillFocusWnd);
   return false;
}

В случае наличия политики также устанавливается перехватчик WH_CBT, который необходим для слежения за фокусом ввода и активациями окон.

Возвращаемся к кошкам-мышкам:

bool CPopupController::PreFilterMessage(LPMSG pMsg, bool preview) {
   if (IPopupPolicy * const pPopupPolicy = GetPopupPolicy()) {
      const IPopupPolicy::ePreFilterResult preFilterResult = pPopupPolicy->PreFilterMessage(pMsg, preview);
      if (preFilterResult == IPopupPolicy::ePreFilterBlockMessage) {
         pMsg->message = WM_NULL;
         return true;
      }
      else if (preFilterResult == IPopupPolicy::ePreFilterAcceptMessage) {
         return false;
      }
      // eContinueRouting
   }
 
   if (Dismissing())
      return false;
   
   bool dismiss = false;
   
   const HWND hCapture = ::GetCapture();   
   const bool isMouseButtonAction = IsMouseButtonAction(pMsg->message);
 
   if (hCapture) {
      if (isMouseButtonAction) {
         POINT ptAction = { GET_X_LPARAM(pMsg->lParam),  GET_Y_LPARAM(pMsg->lParam) };
         ATLVERIFY(::ClientToScreen(hCapture, &ptAction));
 
         const HWND hActionWnd = ::WindowFromPoint(ptAction);
         dismiss = !hActionWnd || hActionWnd != hCapture && !IsOwnerOrSelf(GetPopupHWnd(), hActionWnd);
      }
   }
   else {
      if (isMouseButtonAction) {
         dismiss = !IsOwnerOrSelf(GetPopupHWnd(), pMsg->hwnd);
      }
      else if (pMsg->message == WM_MOUSEMOVE) {
         pMsg->message = WM_NULL;
         return true;
      }
   }
 
   if (dismiss) {
      DismissPopup();
   }
 
   return dismiss;
}

Это код делает следующее:

В первую очередь дает возможность политике фильтровать сообщения
Ничего не делает если режим меню в состоянии закрытия
Выясняет состояние захвата мыши и совершаемое мышью действие
Если мышь захвачена неким окном - нужно выяснить какому окну предназначено сообщение в случае, если бы захват мыши не был установлен вовсе
Если целевое окно - то, которое выполнило захват, одно из его дочерних окон, а также само выпадающее окно (вместе с его содержимым) - сообщение нужно пропустить
В противном случае - выйти из режима меню
Когда захвата мыши нет - выйти из режима меню в случае, когда произвели щелчок по окну вне контекста, а также проглотить сообщение WM_MOUSEMOVE вне контекста. WM_NCMOUSEMOVE я решил пропускать - ничего страшного в этом нет, пускай полосы прокрутки и остальные неклиентские элементы реагируют на происходящее

Зачем нужны все эти танцы с захватом мыши? Чтобы работали элементы управления типа Combo Box, Button и пр. Combo Box, как было описано выше, сам показывает выпадающее окно, используя SetCapture для фильтрации мыши.

Далее рассмотрим подготовку и вход в режим меню. Этим занимается метод ShowPopup:

void CPopupController::ShowPopup(HWND hPopup, HWND hOwner, const POINT &ptAnchor, IPopupPolicy *pPopupPolicy/* = NULL*/)
{
   CPopupManager &manager = CPopupManager::Instance();
 
   ATLASSERT(!manager.IsPopupMode());
   ATLASSERT(!m_hPopup);
   if (manager.IsPopupMode() || m_hPopup)
      return;
   
   const bool popupOk = hPopup && ::IsWindow(hPopup) && ::IsWindowEnabled(hPopup)
                               && (::GetWindowLongPtr(hPopup, GWL_STYLE) & WS_CHILD) == 0
                               && ::GetWindowThreadProcessId(hPopup, NULL) == ::GetCurrentThreadId();
   ATLASSERT(popupOk);
   if (!popupOk)
      return;
 
   if (hOwner && ::IsWindow(hOwner) && (::GetWindowLongPtr(hOwner, GWL_STYLE) & WS_CHILD) != 0) {
      ATLASSERT(FALSE);
      hOwner = ::GetAncestor(hOwner, GA_ROOT);
   }
   else
      hOwner = ::GetActiveWindow();
 
   const bool ownerOk = hOwner && ::GetWindowThreadProcessId(hOwner, NULL) == ::GetCurrentThreadId();
   ATLASSERT(ownerOk);
   if (!ownerOk)
      return;
   
   m_hPopup = hPopup;
   ATLASSERT(GetPopupHWnd() == hPopup);
 
   m_state.reset();
 
   if (const CWindowSubclass &window = CWindowSubclass(GetPopupHWnd(), this)) {
      if (const PopupScope &popupScope = PopupScope(manager, this)) {
         if (pPopupPolicy)
            m_pPopupPolicy = pPopupPolicy;
 
         SetLastError(0);         
         if (!::SetWindowLongPtr(GetPopupHWnd(), GWL_HWNDPARENT, reinterpret_cast<LONG_PTR>(hOwner))) {
            ATLVERIFY(GetLastError() == 0);
         }
         const DWORD swpFlags = SWP_NOSIZE | SWP_NOSENDCHANGING
                                | (m_pPopupPolicy && m_pPopupPolicy->ShowWithoutActivation() ? SWP_NOACTIVATE : 0);
 
         RECT rcWindow = { ptAnchor.x, ptAnchor.y, ptAnchor.x, ptAnchor.y };
         ATLVERIFY(::GetWindowRect(GetPopupHWnd(), &rcWindow));
         const SIZE szWindow = { rcWindow.right - rcWindow.left, rcWindow.bottom - rcWindow.top };
         ATLVERIFY(::CalculatePopupWindowPosition(&ptAnchor, &szWindow, TPM_LEFTALIGN, NULL, &rcWindow));
 
         ATLVERIFY(::SetWindowPos(GetPopupHWnd(), HWND_TOP, rcWindow.left, rcWindow.top, 0, 0, swpFlags));
 
         if (!::IsWindowVisible(GetPopupHWnd())) {
            if (!::AnimateWindow(GetPopupHWnd(), 200, AW_BLEND)) {
               ATLVERIFY(::SetWindowPos(GetPopupHWnd(), HWND_TOP, 0, 0, 0, 0, swpFlags | SWP_NOMOVE | SWP_SHOWWINDOW));
            }
         }
 
         if (!Dismissing() && ::IsWindowVisible(GetPopupHWnd())) {
            do {
               RunMessageLoop();
            } while (Dismissing(false) && m_pPopupPolicy && m_pPopupPolicy->CancelDismiss());
         }
 
         if (pPopupPolicy)
            m_pPopupPolicy = NULL;         
      }
   }
 
   if (::IsWindowVisible(GetPopupHWnd())) {
      ::ShowWindow(GetPopupHWnd(), SW_HIDE);
   }
 
   m_hPopup = NULL;
}

Что здесь происходит:

Проверки состояний менеджера (нельзя входить в режим меню рекурсивно);
Проверки входящих параметров, состояний окон и т.д.;
Контекстный (scoped) сабклассинг окна;
Контекстный (scoped) вход в режим меню;
Привязка окна-владельца к выпадающему окну;
Определение позиции выпадающего окна и его показ (с анимацией, если это возможно);
Цикл циклов сообщений;
Очистка состояния.

Цикл сообщений выглядит следующим образом:

void CPopupController::RunMessageLoop()
{
   ContinueMessageLoop(true);
   
   MSG dummy;
   while (ContinueMessageLoop()) {
      while (::PeekMessage(&dummy, NULL, 0, 0, PM_NOREMOVE)) {
         if (!ContinueMessageLoop()) {
            break;
         }
 
         if (!PumpMessage()) {
            ::PostQuitMessage(0);
            DismissPopup();
            break;
         }
 
         if (!ContinueMessageLoop()) {
            break;
         }
      }
      if (ContinueMessageLoop()) {
         ::WaitMessage();
      }
   }
}

Я вот только что прикинул - цикл сообщений можно было бы перенести в менеджер. Подумаю на досуге.

Важный момент - использование PeekMessage с параметром PM_NOREMOVE. Это сделано для того, чтобы иметь возможность выйти из режима меню до обработки сообщения. Как следствие - иметь возможность не проглатывать сообщение, которое привело к закрытию меню.

Обратите внимание на реализацию PumpMessage:

bool CPopupController::PumpMessage() {
   return m_pEnvironment->PumpMessage();
}

Теперь пример использования этого чуда:

void CChildView::OnRButtonUp(UINT nFlags, CPoint point) {
   POINT ptPopup = point;
   ClientToScreen(&ptPopup);
   
   struct XPopupPolicy : IPopupPolicy
   {
      //virtual bool ShowWithoutActivation() { return false; }
      //virtual eMouseActivateResult MouseActivateAction() { return eNoActivate; }
   };
   
   CPopupDlg popup;
   popup.Create(IDD_POPUP, ::AfxGetMainWnd());
   XPopupPolicy xPopupPolicy;
   CMFCPopupEnvironment mfcPopupEnv;
   CPopupController popupController(&mfcPopupEnv);
   popupController.ShowPopup(popup.GetSafeHwnd(), ::AfxGetMainWnd()->GetSafeHwnd(), ptPopup, &xPopupPolicy);
 
   __super::OnRButtonUp(nFlags, point);
}

Мой диалог содержит пару кнопок и выпадающий список. Все это отлично работает.

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

Код в свободный доступ не выкладываю, жадный. Спасибо за внимание.

Wide monitor in portrait mode

2011-08-20T20:45:00.000+03:00

А вы пробовали установить портретный режим для широкоформатных мониторов?

How to subclass a window multiple times

2011-08-05T15:10:00.000+03:00

Иногда бывает необходимо привязаться к окну и добавить логики по обработке оконных сообщений. Механизм имеет всем известное название сабклассинг. MFC, как и многие библиотеки, поддерживает сабклассинг окон. Проблема лишь в том, что сделать это можно лишь один раз. А если надо много раз? А если к нам попадает хэндл окна и мы понятия не имеем кем оно было создано? Проблемка, однако. Но на помощь как всегда приходит могучий ATL.

#pragma once
 
#include <atlwin.h>
 
class CWindowSubclass
{
 
public:
   CWindowSubclass(CMessageMap *pObject, DWORD msgMapID = 0);
   CWindowSubclass(HWND hWnd, CMessageMap *pObject, DWORD msgMapID = 0);
   ~CWindowSubclass();
 
public:   
   void SwitchMessageMap(DWORD msgMapID);
   BOOL SubclassWindow(HWND hWnd);
   HWND UnsubclassWindow(bool force = false);
   HWND GetHWnd() const;
   operator bool() const;
 
private:   
   static LRESULT CALLBACK WindowProc(HWND hWnd, UINT uMsg, WPARAM wParam, LPARAM lParam);
   LRESULT DefWindowProc(UINT uMsg, WPARAM wParam, LPARAM lParam);   
 
private:
   HWND m_hWnd;
   CWndProcThunk m_thunk;
   WNDPROC m_pfnSuperWindowProc;
   CMessageMap *m_pObject;
   DWORD m_msgMapID;
};

#include "stdafx.h"
#include "WindowSubclass.h"
 
CWindowSubclass::CWindowSubclass(CMessageMap *pObject,  DWORD msgMapID/* = 0*/)
   :  m_hWnd(NULL),         
      m_pObject(pObject),
      m_msgMapID(msgMapID),
      m_pfnSuperWindowProc(NULL)
{
}
 
CWindowSubclass::CWindowSubclass(HWND hWnd,  CMessageMap *pObject, DWORD msgMapID/* = 0*/)
   :  m_hWnd(NULL),
      m_pObject(pObject),
      m_msgMapID(msgMapID),
      m_pfnSuperWindowProc(NULL)
{
   SubclassWindow(hWnd);
}
 
CWindowSubclass::~CWindowSubclass()
{
   if (m_hWnd) {
      UnsubclassWindow(TRUE);
   }
}
 
HWND CWindowSubclass::GetHWnd() const
{
   return(m_hWnd);
}
 
CWindowSubclass::operator bool() const
{
   return m_hWnd != NULL;
}
 
void CWindowSubclass::SwitchMessageMap(DWORD msgMapID)
{
   m_msgMapID = msgMapID;
}
 
LRESULT CWindowSubclass::DefWindowProc(UINT uMsg,  WPARAM wParam,  LPARAM lParam)
{
#ifdef STRICT
   return ::CallWindowProc(m_pfnSuperWindowProc, m_hWnd, uMsg, wParam, lParam);
#else
   return ::CallWindowProc(reinterpret_cast<FARPROC>(m_pfnSuperWindowProc), m_hWnd, uMsg, wParam, lParam);
#endif
}
 
LRESULT CWindowSubclass::WindowProc(HWND hWnd,  UINT uMsg,  WPARAM wParam,  LPARAM lParam)
{
   CWindowSubclass * const pThis = reinterpret_cast<CWindowSubclass *>(hWnd);
 
   ATLASSERT(pThis);
   if (!pThis) {
      return 0;
   }
 
   ATLASSERT(pThis->m_hWnd);
   ATLASSERT(pThis->m_pObject);
   if (!pThis->m_hWnd || !pThis->m_pObject) {
      return 0;
   }
 
   LRESULT lRes = 0;
   BOOL bRet = pThis->m_pObject->ProcessWindowMessage(pThis->m_hWnd, uMsg, wParam, lParam, lRes, pThis->m_msgMapID);
   if (!bRet) {
      if (uMsg != WM_NCDESTROY)
         lRes = pThis->DefWindowProc(uMsg, wParam, lParam);
      else
      {
         const LONG_PTR pfnWndProc = ::GetWindowLongPtr(pThis->m_hWnd, GWLP_WNDPROC);
         lRes = pThis->DefWindowProc(uMsg, wParam, lParam);
         if (pThis->m_pfnSuperWindowProc && ::GetWindowLongPtr(pThis->m_hWnd, GWLP_WNDPROC) == pfnWndProc) {
            ::SetWindowLongPtr(pThis->m_hWnd, GWLP_WNDPROC, reinterpret_cast<LONG_PTR>(pThis->m_pfnSuperWindowProc));
         }
         pThis->m_hWnd = NULL;
      }
   }
   return lRes;
}
 
 
BOOL CWindowSubclass::SubclassWindow(HWND hWnd)
{      
   ATLASSUME(m_hWnd == NULL);
   ATLASSERT(::IsWindow(hWnd));
 
   const BOOL result = m_thunk.Init(WindowProc, this);
   if (result == FALSE)
      return result;
 
   const WNDPROC pProc = m_thunk.GetWNDPROC();
   const WNDPROC pfnWndProc = reinterpret_cast<WNDPROC>(::SetWindowLongPtr(hWnd, GWLP_WNDPROC, reinterpret_cast<LONG_PTR>(pProc)));
   if (pfnWndProc == NULL)
      return FALSE;
   m_pfnSuperWindowProc = pfnWndProc;
   m_hWnd = hWnd;
   return TRUE;
}
 
HWND CWindowSubclass::UnsubclassWindow(bool force/* = false*/)
{
   ATLASSUME(m_hWnd != NULL);
 
   const WNDPROC pOurProc = m_thunk.GetWNDPROC();
   const WNDPROC pActiveProc = reinterpret_cast<WNDPROC>(::GetWindowLongPtr(m_hWnd, GWLP_WNDPROC));
 
   HWND hWnd = NULL;
   if (force || pOurProc == pActiveProc) {
      if (!::SetWindowLongPtr(m_hWnd, GWLP_WNDPROC, reinterpret_cast<LONG_PTR>(m_pfnSuperWindowProc)))
         return NULL;
 
      m_pfnSuperWindowProc = NULL;
      hWnd = m_hWnd;
      m_hWnd = NULL;
   }
   return hWnd;
}

Использовать этот класс проще простого, достаточно передать наследника ATL::CMessageMap в качестве параметра конструктора вместе с дескриптором окна. Плюс привычная для ATL конструкция:

BEGIN_MSG_MAP(MyCMessageMapDerivedClass)
   MESSAGE_HANDLER(WM_MESSAGE, OnMessage)
END_MSG_MAP()

Класс можно использовать множество раз для одного окна. За это спасибо механизму переходников ATL.

Focus and Windows activation (part 1)

2011-07-17T22:27:00.002+03:00

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

Любой UI поток имеет состояние. Это состояние хранится где-то в недрах ОС, но доступно из пользовательского режима при помощи следующих функций:

GetGUIThreadInfo
Это, пожалуй, самая-самая функция, которая демонстрирует составляющие UI состояния потока. Возвращаемая структура GUITHREADINFO хранит следующие значения:
```
 typedef struct tagGUITHREADINFO {
  DWORD cbSize;
  DWORD flags;
  HWND  hwndActive;
  HWND  hwndFocus;
  HWND  hwndCapture;
  HWND  hwndMenuOwner;
  HWND  hwndMoveSize;
  HWND  hwndCaret;
  RECT  rcCaret;
} GUITHREADINFO, *PGUITHREADINFO;
```
1. flags
  Флажки состояний потока - мигающая каретка, меню, окно в процессе изменения размера или положения и т.п.
2. hwndActive
  Дескриптор активного окна потока.
3. hwndFocus
  Дескриптор окна потока, которое имеет логический фокус.
4. hwndCapture
  Дескриптор окна потока, которое захватило мышь вызовом SetCapture.
5. hwndMenuOwner
  Дескриптор окна потока, которое владеет текущим меню.
6. hwndMoveSize
  Дескриптор окна потока, которое в процессе изменения размера или положения.
7. hwndCaret
  Дескриптор окна потока, которое отображает каретку.
8. rcCaret
  Прямоугольная область каретки.
GetActiveWindow
Возвращает значение hwndActive структуры GUITHREADINFO текущего потока.
GetFocus
Возвращает значение hwndFocus структуры GUITHREADINFO текущего потока.
GetCapture
Возвращает значение hwndCapture структуры GUITHREADINFO текущего потока.

В системе может быть активно множество потоков, каждый из которых, являясь UI потоком (IsGUIThread возвращает истину, а также позволяет явно активировать поток в качестве UI потока; эта активация выполняется автоматически в момент первого использования функций для работы с окнами), имеет вышеописанное состояние. Но пользовательский ввод с клавиатуры попадает лишь в определенное окно, дескриптор которого совпадает с hwndFocus одного из потоков. Почему так происходит? Потому, что существует глобальное состояние рабочего стола ОС, а в него входят так называемые Foreground Thread и Foreground Window. Foreground Window - это окно верхнего уровня, которое содержит (или же само таковым является) элемент управления с физическим фокусом. Логический фокус - это состояние потока, физический фокус - состояние рабочего стола и привязка клавиатуры к потоку и окну. Foreground Thread владеет окном с физическим фокусом, в этот поток будут попадать клавиатурные сообщения. Foreground Thread не обязательно владеет Foreground Window, поскольку элемент управления может быть создать в другом потоке и размещен на окне верхнего уровня. Функция GetForegroundWindow позволяет узнать какое окно сейчас активно с точки зрения пользовательского ввода.

Стоит заметить, что Active Window и Foreground Window - это top-level окна, без стиля WS_CHILD, а Focus Window может быть как top-level окном, так и любым его дочерним окном.

Тестовое приложение.

Тестовое приложение состоит из нескольких оконных классов - CTopLevelWnd, CTracingButton и CTracingEdit. Обработчики интересных нам сообщений содержат трассировочный код, который отправляет полезную информацию в лог. Текст окон содержит идентификатор оконного потока, а за ним - дескриптор окна.

Трассировочная информация содержит следующие элементы:

--> отмечает точку входа в обработчик, <-- - выхода; <-> идентифицирует операцию;
далее следует идентификатор текущего потока;
после имя класса (если мы попали в обработчик оконного сообщения);
в скобках указывается дескриптор окна (если это окно либо элемент управления);
потом имя функции или метода с параметрами;
завершает это все статус рабочего стола/потока - Foreground Window (FW), Active Window (AW) и Focused Window (F).

На все потоки установлены хуки WH_GETMESSAGE и WH_CBT, трассирующие интересные события.

Цикл сообщений - свой. Каждому вызову GetMessage предшествует PeekMessage с флагом PM_NOREMOVE. Это сделано для того, чтобы мы видели сообщения, которые вытягивает сам поток, а также сообщения, которые вынимает оттуда ОС без нашего ведома.

Сценарий 1 - активация\деактивация окна приложения.

Рассмотрим следующий сценарий: окно приложения неактивно, окно Notepad активно. Пользователь производит щелчок мышью по текстовому полю ввода окна приложения. Окно активируется, заголовок меняет свой внешний вид, фокус ввода получает поле ввода. Далее щелчок по окну Notepad. Окно деактивируется. Трассировочный лог происходящего приведен ниже, вместе с детальным разбором всех событий.

<-> 1AC4: GetMsgProc(wParam = PM_NOREMOVE, lParam = { message = WM_LBUTTONDOWN } { FW = 0, AW = 0, F = 0 }
--> 1AC4: CTracingEdit(1709F4)::OnMouseActivate(pDesktopWnd = B0B70, nHitTest = 1, message = 513) { FW = 0, AW = 0, F = 0 }
   --> 1AC4: CTopLevelWnd(B0B70)::OnMouseActivate(pDesktopWnd = B0B70, nHitTest = 1, message = 513) { FW = 0, AW = 0, F = 0 }
   <-- 1AC4: CTopLevelWnd(B0B70)::OnMouseActivate(pDesktopWnd = B0B70, nHitTest = 1, message = 513) { FW = 0, AW = 0, F = 0 }
<-- 1AC4: CTopLevelWnd(1709F4)::OnMouseActivate(pDesktopWnd = B0B70, nHitTest = 1, message = 513) { FW = 0, AW = 0, F = 0 }
<-> 1AC4: CBTProc(HCBT_ACTIVATE, hWnd = B0B70, AS = { hWndActive = 0, fMouse = 1 }) { FW = 0, AW = 0, F = 0 }
--> 1AC4: CTopLevelWnd(B0B70)::OnActivateApp(bActive = 1, dwThreadID = 0) { FW = B0B70, AW = B0B70, F = 0 }
<-- 1AC4: CTopLevelWnd(B0B70)::OnActivateApp(bActive = 1, dwThreadID = 0) { FW = B0B70, AW = B0B70, F = 0 }
--> 1AC4: CTopLevelWnd(B0B70)::OnNcActivate(bActive = 1) { FW = B0B70, AW = B0B70, F = 0 }
<-- 1AC4: CTopLevelWnd(B0B70)::OnNcActivate(bActive = 1) { FW = B0B70, AW = B0B70, F = 0 }
--> 1AC4: CTopLevelWnd(B0B70)::OnActivate(nState = 2, pWndOther = 0, bMinimized = 0) { FW = B0B70, AW = B0B70, F = 0 }
   <-> 1AC4: CBTProc(HCBT_SETFOCUS, hSetFocusWnd = B0B70, hKillFocusWnd = 0) { FW = B0B70, AW = B0B70, F = 0 }
   --> 1AC4: CTopLevelWnd(B0B70)::OnSetFocus(pOldWnd = 0) { FW = B0B70, AW = B0B70, F = B0B70 }
   <-- 1AC4: CTopLevelWnd(B0B70)::OnSetFocus(pOldWnd = 0) { FW = B0B70, AW = B0B70, F = B0B70 }
<-- 1AC4: CTopLevelWnd(B0B70)::OnActivate(nState = 2, pWndOther = 0, bMinimized = 0) { FW = B0B70, AW = B0B70, F = B0B70 }
<-> 1AC4: GetMsgProc(wParam = PM_REMOVE, lParam = { message = WM_LBUTTONDOWN } { FW = B0B70, AW = B0B70, F = B0B70 }
--> 1AC4: CTracingEdit(1709F4)::OnLButtonDown(nFlags = 1, point = {114, 10}) { FW = B0B70, AW = B0B70, F = B0B70 }
   <-> 1AC4: CBTProc(HCBT_SETFOCUS, hSetFocusWnd = 1709F4, hKillFocusWnd = B0B70) { FW = B0B70, AW = B0B70, F = B0B70 }
   --> 1AC4: CTopLevelWnd(B0B70)::OnKillFocus(pNewWnd = 1709F4) { FW = B0B70, AW = B0B70, F = 1709F4 }
   <-- 1AC4: CTopLevelWnd(B0B70)::OnKillFocus(pNewWnd = 1709F4) { FW = B0B70, AW = B0B70, F = 1709F4 }
   --> 1AC4: CTracingEdit(1709F4)::OnSetFocus(pOldWnd = B0B70) { FW = B0B70, AW = B0B70, F = 1709F4 }
   <-- 1AC4: CTracingEdit(1709F4)::OnSetFocus(pOldWnd = B0B70) { FW = B0B70, AW = B0B70, F = 1709F4 }
<-- 1AC4: CTracingEdit(1709F4)::OnLButtonDown(nFlags = 1, point = {114, 10}) { FW = B0B70, AW = B0B70, F = 1709F4 }
<-> 1AC4: GetMsgProc(wParam = PM_NOREMOVE, lParam = { message = WM_LBUTTONUP } { FW = B0B70, AW = B0B70, F = 1709F4 }
<-> 1AC4: GetMsgProc(wParam = PM_REMOVE, lParam = { message = WM_LBUTTONUP } { FW = B0B70, AW = B0B70, F = 1709F4 }
--> 1AC4: CTracingEdit(1709F4)::OnLButtonUp(nFlags = 0, point = {114, 10}) { FW = B0B70, AW = B0B70, F = 1709F4 }
<-- 1AC4: CTracingEdit(1709F4)::OnLButtonUp(nFlags = 0, point = {114, 10}) { FW = B0B70, AW = B0B70, F = 1709F4 }

--> 1AC4: CTopLevelWnd(B0B70)::OnNcActivate(bActive = 0) { FW = 0, AW = B0B70, F = 1709F4 }
<-- 1AC4: CTopLevelWnd(B0B70)::OnNcActivate(bActive = 0) { FW = 20830, AW = B0B70, F = 1709F4 }
--> 1AC4: CTopLevelWnd(B0B70)::OnActivate(nState = 0, pWndOther = 0, bMinimized = 0) { FW = 20830, AW = B0B70, F = 1709F4 }
<-- 1AC4: CTopLevelWnd(B0B70)::OnActivate(nState = 0, pWndOther = 0, bMinimized = 0) { FW = 20830, AW = B0B70, F = 1709F4 }
--> 1AC4: CTopLevelWnd(B0B70)::OnActivateApp(bActive = 0, dwThreadID = 370) { FW = 20830, AW = 0, F = 1709F4 }
<-- 1AC4: CTopLevelWnd(B0B70)::OnActivateApp(bActive = 0, dwThreadID = 370) { FW = 20830, AW = 0, F = 1709F4 }
--> 1AC4: CTracingEdit(1709F4)::OnKillFocus(pNewWnd = 0) { FW = 20830, AW = 0, F = 0 }
<-- 1AC4: CTracingEdit(1709F4)::OnKillFocus(pNewWnd = 0) { FW = 20830, AW = 0, F = 0 }

```
<-> 1AC4: GetMsgProc(wParam = PM_NOREMOVE, lParam = { message = WM_LBUTTONDOWN } { FW = 0, AW = 0, F = 0 }
```
В очереди появилось сообщение WM_LBUTTONDOWN. Но ОС пока еще ничего не делает. Действия ниже ОС выполняет лишь когда сообщение изымается из очереди вызовом GetMessage или PeekMessage с флагом PM_REMOVE (а именно эти вызовы будут выше по стеку нежели выполняющийся далее код).

--> 1AC4: CTracingEdit(1709F4)::OnMouseActivate(pDesktopWnd = B0B70, nHitTest = 1, message = 513) { FW = 0, AW = 0, F = 0 }
   --> 1AC4: CTopLevelWnd(B0B70)::OnMouseActivate(pDesktopWnd = B0B70, nHitTest = 1, message = 513) { FW = 0, AW = 0, F = 0 }
   <-- 1AC4: CTopLevelWnd(B0B70)::OnMouseActivate(pDesktopWnd = B0B70, nHitTest = 1, message = 513) { FW = 0, AW = 0, F = 0 }
<-- 1AC4: CTopLevelWnd(1709F4)::OnMouseActivate(pDesktopWnd = B0B70, nHitTest = 1, message = 513) { FW = 0, AW = 0, F = 0 }

Вызван обработчик сообщения WM_MOUSEACTIVATE класса CTracingEdit. ОС посылает это сообщение окну, которое находилось под курсором мыши во время щелчка. Код возврата сообщает ОС что следует делать далее - активировать окно или нет, пропускать сообщение о нажатии или же удалить его из очереди. Обработчик по умолчанию посылает это же сообщение родительскому окну. Обработкик корневых окон возвращает MA_ACTIVATE, что приводит к активации окна и получению сообщений о щелчке.

При такой схеме элемент управления может определить реакцию окна.

Стоит заметить, что сообщение синхронное и его обработчик вызывается из кода режима ядра, управление которому передается вызовом функции GetMessage из кода приложения. Если быть совсем точным, то процедура активации в даном сценарии происходит за один вызов GetMessage, которая в результате вернет WM_LBUTTONDOWN (см. далее).

>	Win32App.exe!CTracingEdit::OnMouseActivate(CWnd * pDesktopWnd, unsigned int nHitTest, unsigned int message)  Line 115	C++
 	Win32App.exe!CWnd::OnWndMsg(unsigned int message, unsigned int wParam, long lParam, long * pResult)  Line 2375 + 0x2f bytes	C++
 	Win32App.exe!CWnd::WindowProc(unsigned int message, unsigned int wParam, long lParam)  Line 2087 + 0x20 bytes	C++
 	Win32App.exe!AfxCallWndProc(CWnd * pWnd, HWND__ * hWnd, unsigned int nMsg, unsigned int wParam, long lParam)  Line 257 + 0x1c bytes	C++
 	Win32App.exe!AfxWndProc(HWND__ * hWnd, unsigned int nMsg, unsigned int wParam, long lParam)  Line 420	C++
 	user32.dll!_InternalCallWinProc@20()  + 0x23 bytes	
 	user32.dll!_UserCallWinProcCheckWow@32()  + 0xb3 bytes	
 	user32.dll!_DispatchClientMessage@20()  + 0x4b bytes	
 	user32.dll!___fnDWORD@4()  + 0x24 bytes	
 	ntdll.dll!_KiUserCallbackDispatcher@12()  + 0x2e bytes	
 	user32.dll!_DispatchClientMessage@20() 	
 	user32.dll!_NtUserGetMessage@16()  + 0xc bytes	
 	user32.dll!_GetMessageW@16()  + 0x2b bytes	
 	Win32App.exe!AfxInternalPumpMessage()  Line 153 + 0x13 bytes	C++
 	Win32App.exe!AfxPumpMessage()  Line 193	C++
 	Win32App.exe!wWinMain(HINSTANCE__ * hInstance, HINSTANCE__ * hPrevInstance, wchar_t * lpCmdLine, int nCmdShow)  Line 135 + 0x5 bytes	C++

```
<-> 1AC4: CBTProc(HCBT_ACTIVATE, hWnd = B0B70, AS = { hWndActive = 0, fMouse = 1 }) { FW = 0, AW = 0, F = 0 }
```
ОС сообщает приложению, что окно B0B70 сейчас будет активировано. Обратите внимание, что Foreground Window (FW), Active Window (AW) и Focused Window (F) - не определены (равны нулю).
```
--> 1AC4: CTopLevelWnd(B0B70)::OnActivateApp(bActive = 1, dwThreadID = 0) { FW = B0B70, AW = B0B70, F = 0 }
<-- 1AC4: CTopLevelWnd(B0B70)::OnActivateApp(bActive = 1, dwThreadID = 0) { FW = B0B70, AW = B0B70, F = 0 }
```
Обработчик сообщения WM_ACTIVATEAPP. Посылается всем окнам верхнего уровня, которые принадлежат потоку активируемого окна, тоесть 1AC4. Окно в этом сценарии всего одно. Foreground Window (FW) и Active Window (AW) уже установлены.

--> 1AC4: CTopLevelWnd(B0B70)::OnNcActivate(bActive = 1) { FW = B0B70, AW = B0B70, F = 0 }
<-- 1AC4: CTopLevelWnd(B0B70)::OnNcActivate(bActive = 1) { FW = B0B70, AW = B0B70, F = 0 }

Обработчик сообщения WM_NCACTIVATE. Код возврата в этом случае игнорируется.

```
--> 1AC4: CTopLevelWnd(B0B70)::OnActivate(nState = 2, pWndOther = 0, bMinimized = 0) { FW = B0B70, AW = B0B70, F = 0 }
```
Обработчик сообщения WM_ACTIVATE. По умолчанию вызывает SetFocus(self), устанавливает фокус на активируемое окно.
```
<-> 1AC4: CBTProc(HCBT_SETFOCUS, hSetFocusWnd = B0B70, hKillFocusWnd = 0) { FW = B0B70, AW = B0B70, F = 0 }
```
ОС сообщает приложению, что фокус ввода собирается переместиться из ниоткуда (hKillFocusWnd = 0) в окно B0B70 (это CTopLevelWnd). Focused Window (F) пока что неопределен.

--> 1AC4: CTopLevelWnd(B0B70)::OnSetFocus(pOldWnd = 0) { FW = B0B70, AW = B0B70, F = B0B70 }
<-- 1AC4: CTopLevelWnd(B0B70)::OnSetFocus(pOldWnd = 0) { FW = B0B70, AW = B0B70, F = B0B70 }

Уведомление о попадании фокуса в окно.

<-- 1AC4: CTopLevelWnd(B0B70)::OnActivate(nState = 2, pWndOther = 0, bMinimized = 0) { FW = B0B70, AW = B0B70, F = B0B70 }

Выход из обработчика WM_ACTIVATE.

```
<-> 1AC4: GetMsgProc(wParam = PM_REMOVE, lParam = { message = WM_LBUTTONDOWN } { FW = B0B70, AW = B0B70, F = B0B70 }
```
Здесь ОС сделала все, что хотела, поэтому собирается вернуть управление в приложение.

--> 1AC4: CTracingEdit(1709F4)::OnLButtonDown(nFlags = 1, point = {116, 13}) { FW = B0B70, AW = B0B70, F = B0B70 }

Нажатие мыши наконец дошло до элемента управления.

```
<-> 1AC4: CBTProc(HCBT_SETFOCUS, hSetFocusWnd = 1709F4, hKillFocusWnd = B0B70) { FW = B0B70, AW = B0B70, F = B0B70 }
```
Эдемент управления реагирует на сообщение изменением фокуса. Поле ввода забирает фокус на себя, о чем говорят следующие строки.

--> 1AC4: CTopLevelWnd(B0B70)::OnKillFocus(pNewWnd = 1709F4) { FW = B0B70, AW = B0B70, F = 1709F4 }
<-- 1AC4: CTopLevelWnd(B0B70)::OnKillFocus(pNewWnd = 1709F4) { FW = B0B70, AW = B0B70, F = 1709F4 }
--> 1AC4: CTracingEdit(1709F4)::OnSetFocus(pOldWnd = B0B70) { FW = B0B70, AW = B0B70, F = 1709F4 }
<-- 1AC4: CTracingEdit(1709F4)::OnSetFocus(pOldWnd = B0B70) { FW = B0B70, AW = B0B70, F = 1709F4 }

<-- 1AC4: CTracingEdit(1709F4)::OnLButtonDown(nFlags = 1, point = {116, 13}) { FW = B0B70, AW = B0B70, F = 1709F4 }

Здесь мы наконец возвращаемся к циклу сообщений.

<-> 1AC4: GetMsgProc(wParam = PM_NOREMOVE, lParam = { message = WM_LBUTTONUP } { FW = B0B70, AW = B0B70, F = 1709F4 }
<-> 1AC4: GetMsgProc(wParam = PM_REMOVE, lParam = { message = WM_LBUTTONUP } { FW = B0B70, AW = B0B70, F = 1709F4 }

И получаем из очереди WM_LBUTTONUP.

--> 1AC4: CTracingEdit(1709F4)::OnLButtonUp(nFlags = 0, point = {116, 13}) { FW = B0B70, AW = B0B70, F = 1709F4 }
<-- 1AC4: CTracingEdit(1709F4)::OnLButtonUp(nFlags = 0, point = {116, 13}) { FW = B0B70, AW = B0B70, F = 1709F4 }

Обработчик которого не делает ничего полезного.

Какие выводы можно сделать из вышенаписанного?

Элементы управления могут управлять активацией корневых окон.
Код ОС, активирующий окна и устанавливающий фокус ввода, выполняется после попадания асинхронного сообщения в очередь и до изымания этого сообщения из очереди приложением (если окно активируется мышью). В противном случае - просто ниже по стеку от вызовов GetMessage или PeekMessage с флагом PM_REMOVE.
Если окно активируется не мышью, а другим способом (Alt-TAB, например), - происходит все то же, за исключением обработчиков WM_MOUSEACTIVATE, WM_LBUTTONDOWN + WM_LBUTTONUP (GetMessage не изымает асинхронные сообщения из очереди, а все процедуры активации происходят без выхода из GetMessage).
ОС не восстанавливает фокус ввода. Если окно было активно и фокус ввода находился на кнопке - то при деактивации и последующей активации он автоматически не вернется обратно на кнопку. За этим нужно сделить самостоятельно. Или воспользоваться оконными процедурами диалоговых окон, которые выполняют эти действия за нас.
Лучшее место для восстановления фокуса - обработчик WM_ACTIVATE. Если при выходе из него фокус все еще неопределен - ОС устанавливает его на активируемое окно, так же, как делает это обработчик WM_ACTIVATE по умолчанию.
При щелчке на элементы управления (кнопки, списки, поля воода) ОС автоматически не устанавливает фокус ввода в целевое окно. Этим занимаются сами элементы управления, обрабатывая WM_?BUTTONDOWN.

При деактивации окна вызываются обработчики сообщений WM_NCACTIVATE, WM_ACTIVATE, WM_ACTIVATEAPP, WM_KILLFOCUS. Обратите внимание как изменяется состояние рабочего стола и потока во время вызова обработчиков по умолчанию. Например на момент входа в CTopLevelWnd::OnNcActivate Foreground Window неопределен (равен нулю), а после вызова обработчика по умолчанию - он уже равен дескриптору окна Notepad. Поскольку пачка всех этих сообщений обрабатывается синхронно - то они посылаются последовательно активирующимся окнам и деактивирующимся, даже если окна принадлежат разным потокам или даже процессам.

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

Object Oriented WinAPI hooks

2011-07-01T22:47:00.000+03:00

Some time ago I was playing with a WH_GETMESSAGE message hook to intercept any mouse and keyboard input. The hook was installed in several UI threads controlled by different application modules. In order to install a message hook, you issue the following code:

const HHOOK hHook = ::SetWindowsHookEx(WH_GETMESSAGE, &GetMsgProc, NULL, ::GetCurrentThreadId());

and your GetMsgProc looks like this one:

LRESULT CALLBACK GetMsgProc(int code, WPARAM wParam, LPARAM lParam)
{
   // Extra work here...
   return ::CallNextHookEx(NULL, code, wParam, lParam);
}

What if you need to pass control over to some object, invoke a member function? Keep in mind that GetMsgProc is a free function (that doesn't receive hook handle in its parameters). Therefore you can't use anything to map invocation context to OOP world citizens. You could use a global object to overcome this issue, but still you can't install more than one message hook with the same callback function.

So the only thing that can map to an object ... is the callback function itself. Hopefully, we are able to create that function on the fly, in memory:

struct IGetMessageHookTarget
{
   virtual LRESULT GetMsgProc(int code, WPARAM wParam, LPARAM lParam)
   {
      return ::CallNextHookEx(NULL, code, wParam, lParam);
   }
};

class GetMessageHook : IGetMessageHookTarget
{
   static const size_t ProcSize = 18;
public:
   GetMessageHook() {
      BYTE getMsgProcBytes[ProcSize] =
      {
         0x55,                           // push        ebp
         0x8B, 0xEC,                     // mov         ebp,esp
         0xA1, 0x00, 0x00, 0x00, 0x00,   // mov         eax,dword ptr ds:[this]
         0xB9, 0x00, 0x00, 0x00, 0x00,   // mov         ecx,this
         0x8B, 0x10,                     // mov         edx,dword ptr [eax]
         0x5D,                           // pop         ebp
         0xFF, 0xE2,                     // jmp         edx
      };

      *reinterpret_cast<size_t *>(&getMsgProcBytes[4]) = reinterpret_cast<size_t>(this);
      *reinterpret_cast<size_t *>(&getMsgProcBytes[4 + 1 + sizeof(size_t)]) = reinterpret_cast<size_t>(this);

      const HANDLE hCurrentProcess = ::GetCurrentProcess();
      _getMsgProcBytes = ::VirtualAllocEx(hCurrentProcess, NULL, ProcSize, MEM_COMMIT | MEM_RESERVE, PAGE_EXECUTE_READWRITE);
      CopyMemory(_getMsgProcBytes, getMsgProcBytes, sizeof(getMsgProcBytes));
      ::VirtualProtectEx(hCurrentProcess, _getMsgProcBytes, ProcSize, PAGE_EXECUTE, NULL);
      
      _hHook = ::SetWindowsHookEx(WH_GETMESSAGE, reinterpret_cast<HOOKPROC>(_getMsgProcBytes), NULL, ::GetCurrentThreadId());
   }

   ~GetMessageHook() {
      ::UnhookWindowsHookEx(_hHook);
      ::VirtualFreeEx(::GetCurrentProcess(), _getMsgProcBytes, ProcSize, MEM_RELEASE);
   }

protected:
   virtual LRESULT GetMsgProc(int code, WPARAM wParam, LPARAM lParam)
   {
      return ::CallNextHookEx(NULL, code, wParam, lParam);
   }

private:
   HHOOK _hHook;
   LPVOID _getMsgProcBytes;
};

GetMessageHook constructor creates an in-memory code that passes control over to GetMsgProc member function. Believe me - it works. At least on x86.

Herman Miller Embody and Aeron

2011-05-27T09:37:00.000+03:00

В семье пополнение...

Cavalcade of Cartoon Comedy

2011-05-20T15:02:00.000+03:00

Наткнулся на серию мультфильмов-пародий, называется Кавалькада мультипликационных комедий / Cavalcade of Cartoon Comedy (Seth MacFarlane / Сет Макфарлейн) 2008 г.

How to prevent MFC dialog closing on Enter and Escape keys

2011-05-18T20:49:00.002+03:00

In this article I explain how to prevent an MFC dialog from handling the Enter and Escape keys and not pass it on. With all required details for you to completely understand why does it work the way it does. There are several possible solutions, so you can choose the most suitable one.

The problem is the following: you have a dialog, no matter - top level window or just a child container; you press Escape or Enter keys - the dialog disappears, even if there are no OK and Cancel buttons on the dialog. It's very funny seeing a child dialog drops out it's parent.

Let's see why this happens:

OrderXMLReaderShell.exe!CFilterEditorDlgBase::OnCancel()  Line 61 C++
  mfc100ud.dll!_AfxDispatchCmdMsg(CCmdTarget * pTarget, unsigned int nID, int nCode, void (void)* pfn, void * pExtra, unsigned int nSig, AFX_CMDHANDLERINFO * pHandlerInfo)  Line 82 C++
  mfc100ud.dll!CCmdTarget::OnCmdMsg(unsigned int nID, int nCode, void * pExtra, AFX_CMDHANDLERINFO * pHandlerInfo)  Line 381 + 0x27 bytes C++
  mfc100ud.dll!CDialog::OnCmdMsg(unsigned int nID, int nCode, void * pExtra, AFX_CMDHANDLERINFO * pHandlerInfo)  Line 87 + 0x18 bytes C++
  mfc100ud.dll!CWnd::OnCommand(unsigned int wParam, long lParam)  Line 2729 C++
  mfc100ud.dll!CWnd::OnWndMsg(unsigned int message, unsigned int wParam, long lParam, long * pResult)  Line 2101 + 0x1e bytes C++
  mfc100ud.dll!CWnd::WindowProc(unsigned int message, unsigned int wParam, long lParam)  Line 2087 + 0x20 bytes C++
  mfc100ud.dll!AfxCallWndProc(CWnd * pWnd, HWND__ * hWnd, unsigned int nMsg, unsigned int wParam, long lParam)  Line 257 + 0x1c bytes C++
  mfc100ud.dll!AfxWndProc(HWND__ * hWnd, unsigned int nMsg, unsigned int wParam, long lParam)  Line 420 C++
  mfc100ud.dll!AfxWndProcBase(HWND__ * hWnd, unsigned int nMsg, unsigned int wParam, long lParam)  Line 420 + 0x15 bytes C++
  user32.dll!_InternalCallWinProc@20()  + 0x23 bytes 
  user32.dll!_UserCallWinProcCheckWow@32()  + 0xb3 bytes 
  user32.dll!_SendMessageWorker@20()  + 0xee bytes 
  user32.dll!_SendMessageW@16()  + 0x49 bytes 
  user32.dll!_IsDialogMessageW@8()  + 0xef46 bytes 
> mfc100ud.dll!CWnd::IsDialogMessageW(tagMSG * lpMsg)  Line 198 C++
  mfc100ud.dll!CWnd::PreTranslateInput(tagMSG * lpMsg)  Line 4713 C++
  mfc100ud.dll!CDialog::PreTranslateMessage(tagMSG * pMsg)  Line 82 C++
  OrderXMLReaderShell.exe!CFindDlg::PreTranslateMessage(tagMSG * pMsg)  Line 56 C++
  mfc100ud.dll!CWnd::WalkPreTranslateTree(HWND__ * hWndStop, tagMSG * pMsg)  Line 3311 + 0x14 bytes C++
  mfc100ud.dll!AfxInternalPreTranslateMessage(tagMSG * pMsg)  Line 233 + 0x12 bytes C++
  mfc100ud.dll!CWinThread::PreTranslateMessage(tagMSG * pMsg)  Line 777 + 0x9 bytes C++
  mfc100ud.dll!AfxPreTranslateMessage(tagMSG * pMsg)  Line 252 + 0x11 bytes C++
  mfc100ud.dll!AfxInternalPumpMessage()  Line 178 + 0x18 bytes C++
  mfc100ud.dll!CWinThread::PumpMessage()  Line 900 C++
  mfc100ud.dll!CWinThread::Run()  Line 629 + 0xd bytes C++
  mfc100ud.dll!CWinApp::Run()  Line 832 C++
  mfc100ud.dll!AfxWinMain(HINSTANCE__ * hInstance, HINSTANCE__ * hPrevInstance, wchar_t * lpCmdLine, int nCmdShow)  Line 47 + 0xd bytes C++
  OrderXMLReaderShell.exe!wWinMain(HINSTANCE__ * hInstance, HINSTANCE__ * hPrevInstance, wchar_t * lpCmdLine, int nCmdShow)  Line 26 C++
  OrderXMLReaderShell.exe!__tmainCRTStartup()  Line 547 + 0x2c bytes C
  OrderXMLReaderShell.exe!wWinMainCRTStartup()  Line 371 C
  kernel32.dll!@BaseThreadInitThunk@12()  + 0x12 bytes 
  ntdll.dll!___RtlUserThreadStart@8()  + 0x27 bytes 
  ntdll.dll!__RtlUserThreadStart@8()  + 0x1b bytes

The execution flow got into CDialog::OnCancel virtual method. Here is the default MFC's implementation:

void CDialog::OnCancel()
{
 EndDialog(IDCANCEL);
}

It simply ends the dialog, thus destroying the window.

Lets find out how do we get there. The control flow is the following:

Escape key is down
WM_KEYDOWN message is queued into message queue
AfxInternalPumpMessage gets the message from the queue and invokes AfxPreTranslateMessage
CWnd::IsDialogMessage is reached
IsDialogMessage WinAPI function is called by CWnd::IsDialogMessage; this function is the core of dialog management - it does things like keyboard navigation.
There is a user32.dll!_SendMessageW@16() call from IsDialogMessageW
Which brings us to CWnd::OnCommand with wParam equals to IDCANCEL
End finally to CDialog::OnCancel

IsDialogMessageW examines the message and invokes SendMessage(hwndDlg, WM_COMMAND, MAKELONG(IDCANCEL, BN_CLICKED), ...);.

Short summary - MFC calls IsDialogMessage API function, which in turns emulates IDCANCEL button click, which is being handled by MFC eventually destroying the dialog.

It is not obvious why IsDialogMessageW emulates IDOK and IDCANCEL button clicks. I believe this is done to make developer's life easier. Imagine you have no control over the message loop, can't do any message pre translation. You'll have to handle Enter and Escape keys for every control on the dialog. That's pain.

What can we do to solve the problem? You can't change OS behavior for sure, but can do the following:

Override CDialog::OnOK/OnCancel and do nothing
The following applies:
- Dialog is not destroyed on Enter or Escape
- Focused inline controls don't receive WM_KEYDOWN for VK_ENTER and VK_ESCAPE codes
- OK/Cancel button clicks have no effect
Override CDialog::PreTranslateMessage and don't call the base if pMsg->message == WM_KEYDOWN && (pMsg->wParam == VK_ESCAPE || pMsg->wParam == VK_RETURN)
If CDialog::PreTranslateMessage returns TRUE the following applies:
- Dialog is not destroyed on Enter or Escape
- Focused inline controls don't receive WM_KEYDOWN for VK_RETURN and VK_ESCAPE codes, unless you do dispatch them before CDialog::PreTranslateMessage returns
- OK/Cancel button clicks have desired effect
If CDialog::PreTranslateMessage returns FALSE the following applies:
- MFC calls parent's PreTranslateMessage (which brings us back if the parent is a CDialog instance)
Override CWinThread::PreTranslateMessage, examine the message and don't call the base
The following applies:
- CWnd::WalkPreTranslateTree is not invoked, thus disabling message pre translation along with IsDialogMessage call (specific messages only, it's not as scary as it seems, but hits the performance and hard to implement properly)
  If CWinThread::PreTranslateMessage returns TRUE the following applies:
  - Message is not dispatched
  - Focused inline controls don't receive WM_KEYDOWN for VK_RETURN and VK_ESCAPE codes
  If CWinThread::PreTranslateMessage returns FALSE the following applies:
  - Message is dispatched
  - Focused inline controls receive WM_KEYDOWN for VK_RETURN and VK_ESCAPE codes
- The behavior is application wide

The very best option would be to override CWnd::IsDialogMessage and return in case of VK_RETURN and VK_ESCAPE, but this is impossible since CWnd::IsDialogMessage is not virtual. CWnd::IsDialogMessage is an API function wrapper, the closest item to modify the behavior.

So which method is the best? Each does the trick, but... Option 3 has serious drawback. Option 1 and 2 are class specific. I vote for option 2. You could create some base CDialog class with the trick and use it for all your dialogs.

Funny site error

2011-05-15T23:55:00.002+03:00

Misspelling

2011-04-20T22:25:00.000+03:00

Fucking Date and Time Picker Controls or how to close DateTimePicker programmatically

2011-03-29T19:19:00.001+03:00

Только что закончил фикс милейшего дефекта. DateTimePicker вываливал окно календаря и при щелчках мышью по заголовку родительского окна или в другие области оно оставалось висеть пока не выбрана дата.

Происходило это потому, что элемент управления DateTimePicker был создан в потоке отличном от потока окна верхнего уровня, в котором он находится. Да, знаю, многозадачный UI - это зло, но имеем то, что имеем.

В результате исследования выяснилось, что начиная с Windows Vista этой проблемы больше нет - окно закрывается в любом случае (маленькая поправочка - при использовании 6-й версии библиотеки comctl32). На Windows XP проблема имеет место быть в не зависимости от версии comctl32.

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

Сначала показалось, что задачка из простых - было найдено сообщение DTM_CLOSEMONTHCAL, которое выполняет нужную функцию. После попытки разобраться почему вариант не рабочий выяснилось, что Minimum supported client - Windows Vista. А нам для Windows XP. Блядь-блядь-блядь!!!

Хрен с ним, решение все равно есть. Достаточно лишь понять как работает DateTimePicker. А он закрывает month calendar при нажатии клавиши Escape, а также при некоторых манипуляциях мышью. Также следует учесть, что элемент управления не теряет фокус во время отображения окна month calendar, а само выпадающее окно никогда не активируется.

Первое, что пришло в голову, - эмулировать нажатие Escape когда month calendar нужно закрыть програмно - выполнить SendKeys.SendWait("{ESC}");. Вариант оказался не рабочий. Причина весьма коварна - вызов этого метода запускает вложенный цикл сообщений и крутит его до тех пор, пока внедренные сообщения о нажатии клавиш не будут обработаны. А еще DateTimePicker запускает свой цикл сообщений, когда показывает окно календаря:

  user32.dll!_NtUserGetMessage@16()  + 0xc bytes 
  comctl32.dll!_DPLBD_MonthCal@8()  + 0x244 bytes 
  comctl32.dll!_DPLButtonDown@12()  + 0x79 bytes 
  comctl32.dll!_DatePickWndProc@16()  + 0x56b bytes 
  user32.dll!_InternalCallWinProc@20()  + 0x28 bytes 
  user32.dll!_UserCallWinProcCheckWow@32()  + 0xb7 bytes 
  user32.dll!_CallWindowProcAorW@24()  + 0x51 bytes 
  user32.dll!_CallWindowProcW@20()  + 0x1b bytes 
  System.Windows.Forms.dll!System.Windows.Forms.NativeWindow.DefWndProc(ref System.Windows.Forms.Message m) Line 810 + 0x31 bytes C#
  System.Windows.Forms.dll!System.Windows.Forms.Control.DefWndProc(ref System.Windows.Forms.Message m) Line 5729 + 0xa bytes C#
  System.Windows.Forms.dll!System.Windows.Forms.Control.WmMouseDown(ref System.Windows.Forms.Message m, System.Windows.Forms.MouseButtons button, int clicks) Line 12909 + 0xc bytes C#
  System.Windows.Forms.dll!System.Windows.Forms.Control.WndProc(ref System.Windows.Forms.Message m) Line 13761 C#
  System.Windows.Forms.dll!System.Windows.Forms.DateTimePicker.WndProc(ref System.Windows.Forms.Message m) Line 1686 C#

В этом цикле содержится логика закрытия окна календаря. Одно из ее составляющих - ожидание сообщения WM_KEYDOWN с VK_ESC. Сообщение при этом глотается, до окна оно не доходит. Именно поэтому первая попытка провалилась. Выход - использовать SendKeys.Send("{ESC}");, неблокирующий вызов, который не запускает вложенный цикл обработки сообщений, просто вставляет в очередь необходимые сообщения, которые в последствии обрабатываются циклом сообщений внутри DPLBD_MonthCal. Мне он тоже не подошел т.к. активировалось другое окно и оно же получало нажатие Escape. В результате я просто делаю Win32.PostMessage(Handle, Win32.WM_KEYDOWN, Win32.VK_ESC, IntPtr.Zero); и все пучком. Код стероидов:

/// <summary>
/// Month calendar visibility.
/// </summary>
public bool IsMonthCalendarShown
{
    get
    {
        return (IsHandleCreated
                && Win32.SendMessage(Handle, Win32.DTM_GETMONTHCAL, IntPtr.Zero, IntPtr.Zero) != IntPtr.Zero);
    }
}

/// <summary>
/// Closes month calendar if visible.
/// </summary>
/// <remarks>
/// This is guaranteed to work on Windows Vista and above. Under Windows XP this method uses a hack.
/// </remarks>
public void CloseMonthCalendar()
{
    if (!IsMonthCalendarShown)
    {
        return;
    }

    if (Win32.HasVistaAPI)
    {
        Win32.SendMessage(Handle, Win32.DTM_CLOSEMONTHCAL, IntPtr.Zero, IntPtr.Zero);
    }
    else
    {
        // NOTE: SendKeys.Send[Wait] can't be used here!
        // comctl32 runs its own message loop and awaits for WM_KEYDOWN with VK_ESC. It doesn't dispatch that however,
        // rather closes the month calendar instead. SendKeys.SendWait calls Application.DoEvents() which
        // runs message loop and does dispatch WM_KEY**** messages. So the month calendar is not closed.
        // SendKeys.Send might send input to wrong window (one being activated by mouse).
        //
        // HACK: So the only option here is to post WM_KEYDOWN with VK_ESC.
        //
        Win32.PostMessage(Handle, Win32.WM_KEYDOWN, Win32.VK_ESC, IntPtr.Zero);
    }
}

SendKeys suck

2011-03-26T16:20:00.001+02:00

Недавно пришлось поколупаться в исходном коде класса SendKeys. Его отвратительное качество меня просто поразило. Но самый больший ахуй случился когда я там наткнулся на следующий WTF:

[System.Diagnostics.CodeAnalysis.SuppressMessage("Microsoft.Design", "CA1031:DoNotCatchGeneralExceptionTypes")] 
private static void LoadSendMethodFromConfig()
{ 
   if (!sendMethod.HasValue) 
   {
       sendMethod = SendMethodTypes.Default; 

       try
       {
           // read SendKeys value from config file, not case sensitive 
           string value = System.Configuration.ConfigurationManager.AppSettings.Get("SendKeys");
 
           if (value.Equals("JournalHook", StringComparison.OrdinalIgnoreCase)) 
               sendMethod = SendMethodTypes.JournalHook;
           else if (value.Equals("SendInput", StringComparison.OrdinalIgnoreCase)) 
               sendMethod = SendMethodTypes.SendInput;
       }
       catch {} // ignore any exceptions to keep existing SendKeys behavior
   } 
}

Если в файле конфигурации приложения отсутствует настройка SendKeys - value.Equals вываливает NullReferenceException, который успешно тушится блоком catch {}. Это пиздец, господа. Класс писал студент в качестве тестового задания для Microsoft? Не удивительно, что во фреймворке столько говнокода, ведь студента видимо приняли.

How to make CDialog inherit parent background color

2011-02-22T23:20:00.000+02:00

Частенько бывает удобно встраивать один диалог в другой в качестве дочернего элемента управления. Все просто - ставим стили:

STYLE DS_CONTROL | WS_CHILD
EXSTYLE WS_EX_CONTROLPARENT

и создаем окно вызовом CDialog::Create.

Одна из проблем - диалог не запрашивает у родителя цвет для своего фона. В результате вложенный диалог другого цвета. Одно из решений - пробрасывать обработку сообщения WM_CTLCOLOR выше по иерархии окон:

struct AFX_CTLCOLOR
{
 HWND hWnd;
 HDC hDC;
 UINT nCtlType;
};
 
afx_msg HBRUSH CFontChooser::OnCtlColor(CDC *pDC, CWnd *pWnd, UINT nCtlColor) {
 if (GetStyle() & WS_CHILD) {
 AFX_CTLCOLOR ctl;
 ctl.hDC = pDC->GetSafeHdc();
 ctl.hWnd = pWnd->GetSafeHwnd();
 ctl.nCtlType = nCtlColor;
 
 return(reinterpret_cast<HBRUSH>(GetParent()->SendMessage(WM_CTLCOLOR, 0, reinterpret_cast<LPARAM>(&ctl))));
 }
 
 return(__super::OnCtlColor(pDC, pWnd, nCtlColor));
}

Проблемка здесь в том, что WM_CTLCOLOR эмулируется средствами MFC. Для этого используется локальная для библиотечного cpp-файла структурка AFX_CTLCOLOR. Которую пришлось сдублировать у себя в коде...

Russian mentality

2011-02-22T13:16:00.003+02:00

Вот что такое Россия с точки зрения охраны секретных сведений?

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

Взять хоть эту гостиницу. К каждому приезжающему отношение сверхбдительное: извольте документы на прописку, да по какой надобности изволили прибыть, да нельзя ли получить телеграфное подтверждение от командирующей инстанции. Военный порт, неприступная крепость! Горничная баба Катя в первую же отлучку обшарила весь багаж, аж носовые платки перебрала (это Зепп установил по приставшему к батисту длинному полуседому волосу). То ли тетка в морской контрразведке подрабатывает, то ли просто энтузиастка — под предлогом патриотической бдительности удовлетворяет женское любопытство. И что же? Довольно было угостить пожилую фрау чаем, выслушать рассказ о нелегкой женской доле, самому посетовать на горькую судьбину вдовца с шестью крошками на руках (имелись и фотокарточки крошек, а как же) — и сделалась Катюша верной союзницей. Стала называть «сынком», все секреты выложила — и про полового Мишку, который филер, и про обязательную «лепортацию» о каждом постояльце. А всё потому что Зепп стал для нее свой.

Своим в России можно всё, правила написаны для чужих. Поэтому и законы здесь не более чем условность, удобная для сильных и досадная для слабых. Недаром сакральный лозунг русских — «жить по правде». Но правда-то у каждого своя. Это право, то бишь закон, для всех общий, а общее — оно заведомо не свое.

Именно здесь, на стыке общего и своего, казенного и личного, угадывалась замочная скважина. Только Зепп никак не мог нащупать ее отмычкой.

How to force raw pointer marshaling when doing automatic COM marshaling

2011-01-30T21:33:00.000+02:00

Иногда требуется запретить выполнять стандартный маршалинг указателя на интерфейс средствами OLE32. Например, я хочу использовать некий интерфейс IFoo из .NET-а, реализация которого попала в CLR из неуправляемого кода, при этом информации в реестре по этому интерфейсу нет (proxy/stub и tlb не зарегистрированы). Как было неоднократно показано в предыдущих заметках о взаимодействии управляемого и неуправляемого кода, при попытке использовать IFoo из другого потока получим исключение.

Избежать автоматического маршалинга указателя на интерфейс можно, самостоятельно реализовав IMarshal. Но тут кроется еще одна засада - метод GetUnmarshalClass обязан возвратить CLSID класса, который будет выполнять роль proxy. И этот класс должен быть зарегистрирован, что нам явно не подходит.

На помощь приходит функция CoCreateFreeThreadedMarshaler, которая выполняет всю грязную работу по получению необходимой функциональности. Результирующий объект нужно подключить, как tear-off реализацию IMarshal к требуемому классу.

RCW vs Garbage Collector

2011-01-17T19:04:00.000+02:00

Недавно столкнулись с проблемой - вызов GC.WaitForPendingFinalizers(); блокировал работу приложения. На мысли навела следующая часть стека:

  [In a sleep, wait, or join] 
  ntdll.dll!_KiFastSystemCallRet@0()  
  ntdll.dll!_NtWaitForMultipleObjects@20()  + 0xc bytes 
  KernelBase.dll!_WaitForMultipleObjectsEx@20()  - 0x54 bytes 
  kernel32.dll!_WaitForMultipleObjectsExImplementation@20()  + 0x8e bytes 
  user32.dll!_RealMsgWaitForMultipleObjectsEx@20()  + 0xd7 bytes 
  ole32.dll!CCliModalLoop::BlockFn()  + 0x96 bytes 
  ole32.dll!_CoWaitForMultipleHandles@20()  - 0x51b9 bytes 
  [Managed to Native Transition] 
  mscorlib.dll!System.GC.WaitForPendingFinalizers() + 0x2c bytes

Блокировка происходит из ole32.dll. После просмотра стеков всех остальных потоков был найден следующий любопытный житель нашего процесса:

> ntdll.dll!_KiFastSystemCallRet@0()  
  ntdll.dll!_ZwWaitForSingleObject@12()  + 0xc bytes 
  KernelBase.dll!_WaitForSingleObjectEx@12()  + 0x6c bytes 
  kernel32.dll!_WaitForSingleObjectExImplementation@12()  + 0x43 bytes 
  kernel32.dll!_WaitForSingleObject@8()  + 0x12 bytes 
  ole32.dll!GetToSTA()  + 0x72 bytes 
  ole32.dll!CRpcChannelBuffer::SwitchAptAndDispatchCall()  - 0x1939 bytes 
  ole32.dll!CRpcChannelBuffer::SendReceive2()  + 0xa6 bytes 
  ole32.dll!CAptRpcChnl::SendReceive()  + 0x5b7 bytes 
  ole32.dll!CCtxComChnl::SendReceive()  - 0x14b97 bytes 
  ole32.dll!NdrExtpProxySendReceive()  + 0x43 bytes 
  rpcrt4.dll!@NdrpProxySendReceive@4()  + 0xe bytes 
  rpcrt4.dll!_NdrClientCall2()  + 0x144 bytes 
  ole32.dll!_ObjectStublessClient@8()  + 0x7a bytes 
  ole32.dll!_ObjectStubless@0()  + 0xf bytes 
  ole32.dll!CObjectContext::InternalContextCallback()  - 0x511f bytes 
  ole32.dll!CObjectContext::ContextCallback()  + 0x8f bytes 
  clr.dll!CtxEntry::EnterContext()  + 0x119 bytes 
  clr.dll!RCWCleanupList::ReleaseRCWListInCorrectCtx()  + 0x2bb bytes 
  clr.dll!RCWCleanupList::CleanupAllWrappers()  - 0x2ef04 bytes 
  clr.dll!SyncBlockCache::CleanupSyncBlocks()  + 0xa6a bytes 
  clr.dll!Thread::DoExtraWorkForFinalizer()  - 0x4c12 bytes 
  clr.dll!WKS::GCHeap::FinalizerThreadWorker()  + 0x8b bytes 
  clr.dll!Thread::DoExtraWorkForFinalizer()  + 0x3e0ff bytes 
  clr.dll!Thread::ShouldChangeAbortToUnload()  - 0x5f4 bytes 
  clr.dll!Thread::ShouldChangeAbortToUnload()  - 0x539 bytes 
  clr.dll!ManagedThreadBase_NoADTransition()  + 0x35 bytes 
  clr.dll!ManagedThreadBase::FinalizerBase()  + 0xf bytes 
  clr.dll!WKS::GCHeap::FinalizerThreadStart()  + 0xfb bytes 
  clr.dll!Thread::intermediateThreadProc()  + 0x48 bytes 
  kernel32.dll!@BaseThreadInitThunk@12()  + 0x12 bytes 
  ntdll.dll!___RtlUserThreadStart@8()  + 0x27 bytes 
  ntdll.dll!__RtlUserThreadStart@8()  + 0x1b bytes

Перед нами стек так называемого Finalizer Thread, который выполняет работу по освобождению ресурсов. Из стека стало ясно, что этот поток пытается избавиться от ненужных RCW. Для этого он вызывает метод Release каждого COM-объекта, но пытается сделать это в другом контексте. Очевидно, что этот контекст - это апартмент из которого объект попал в CLR. В моем случае поток, соответствующий этому апартменту, не обрабатывал асинхронные сообщения, а именно ими обменивается ole32.dll для маршалинга вызовов между контекстами.

Ахтунг состоит в том, что Finalizer Thread является чужеродным контекстом для всех COM-объектов, которые попали в CLR (за исключением тех, которые были созданы в контексте самого Finalizer Thread, а это вполне реальная ситуация). Как же в результате происходит освобождение ресурсов, если вызов GC.WaitForPendingFinalizers(); блокируется до полной очистки всего накопившегося мусора? Ответ находится на вешине первого стека:

> CPPHost.exe!CNETFormControllerCallback::~CNETFormControllerCallback()  Line 13 C++
  CPPHost.exe!ATL::CComObjectNoLock<CNETFormControllerCallback>::~CComObjectNoLock<CNETFormControllerCallback>()  Line 3037 + 0xf bytes C++
  CPPHost.exe!ATL::CComObjectNoLock<CNETFormControllerCallback>::`scalar deleting destructor'()  + 0x2b bytes C++
  CPPHost.exe!ATL::CComObjectNoLock<CNETFormControllerCallback>::Release()  Line 3049 + 0x35 bytes C++
  CPPHost.exe!ATL::_QIThunk::Release()  Line 2692 + 0x10 bytes C++
  ole32.dll!CRemoteUnknown::DoCallback()  + 0x3b bytes 
  rpcrt4.dll!_Invoke@12()  + 0x2a bytes 
  rpcrt4.dll!_NdrStubCall2@16()  + 0x22f bytes 
  ole32.dll!_CStdStubBuffer_Invoke@12()  + 0x70 bytes 
  ole32.dll!SyncStubInvoke()  + 0x34 bytes 
  ole32.dll!StubInvoke()  + 0x7b bytes 
  ole32.dll!CCtxComChnl::ContextInvoke()  + 0xe6 bytes 
  ole32.dll!MTAInvoke()  + 0x1a bytes 
  ole32.dll!STAInvoke()  + 0x4a bytes 
  ole32.dll!AppInvoke()  + 0x92 bytes 
  ole32.dll!ComInvokeWithLockAndIPID()  + 0x27c bytes 
  ole32.dll!ComInvoke()  + 0x71 bytes 
  ole32.dll!ThreadDispatch()  + 0x1a bytes 
  ole32.dll!ThreadWndProc()  + 0xa0 bytes 
  user32.dll!_InternalCallWinProc@20()  + 0x23 bytes 
  user32.dll!_UserCallWinProcCheckWow@32()  + 0xb3 bytes 
  user32.dll!_DispatchMessageWorker@8()  + 0xe6 bytes 
  user32.dll!_DispatchMessageW@4()  + 0xf bytes 
  ole32.dll!CCliModalLoop::PeekRPCAndDDEMessage()  + 0x241 bytes 
  ole32.dll!CCliModalLoop::BlockFn()  - 0x5d50 bytes 
  ole32.dll!_CoWaitForMultipleHandles@20()  - 0x51b9 bytes 
  [Managed to Native Transition] 
  mscorlib.dll!System.GC.WaitForPendingFinalizers() + 0x2c bytes 
  NETLibrary.dll!NETLibrary.NETFormController.GCAndWaitForPendingFinalizers() Line 33 + 0x5 bytes C#
  [Native to Managed Transition] 
  CPPHost.exe!NETLibrary::INETFormController::GCAndWaitForPendingFinalizers()  Line 67 + 0x10 bytes C++
  CPPHost.exe!wmain(int argc=1, wchar_t * * argv=0x006832d8)  Line 107 C++

Здесь видно, что GC.WaitForPendingFinalizers(); блокирует выполнение потока вызовом CoWaitForMultipleHandles, который крутит цикл сообщений для обработки входящих COM-вызовов. Мощно, да?

Допустим, что COM-объект попал в CLR из потока, отличного от того, в котором происходит вызов GC.WaitForPendingFinalizers();, но сам поток к моменту вызова не может обработать входящий вызов (поток завершил работу, например):

> CPPHost.exe!CNETFormControllerCallback::~CNETFormControllerCallback()  Line 13 C++
  CPPHost.exe!ATL::CComObjectNoLock<CNETFormControllerCallback>::~CComObjectNoLock<CNETFormControllerCallback>()  Line 3037 + 0xf bytes C++
  CPPHost.exe!ATL::CComObjectNoLock<CNETFormControllerCallback>::`scalar deleting destructor'()  + 0x2b bytes C++
  CPPHost.exe!ATL::CComObjectNoLock<CNETFormControllerCallback>::Release()  Line 3049 + 0x35 bytes C++
  CPPHost.exe!ATL::_QIThunk::Release()  Line 2692 + 0x10 bytes C++
  clr.dll!ReleaseTransitionHelper()  + 0xe bytes 
  clr.dll!SafeReleaseHelper()  + 0x6b bytes 
  clr.dll!SafeRelease()  + 0x2f bytes 
  clr.dll!IUnkEntry::Free()  + 0x4e bytes 
  clr.dll!RCW::ReleaseAllInterfaces()  + 0x1a bytes 
  clr.dll!RCW::ReleaseAllInterfacesCallBack()  + 0x178b5c bytes 
  clr.dll!RCW::Cleanup()  + 0x22 bytes 
  clr.dll!RCWCleanupList::ReleaseRCWListRaw()  + 0x18 bytes 
  clr.dll!RCWCleanupList::ReleaseRCWListInCorrectCtx()  + 0x17a15e bytes 
  clr.dll!RCWCleanupList::CleanupAllWrappers()  - 0x2ef04 bytes 
  clr.dll!SyncBlockCache::CleanupSyncBlocks()  + 0xa6a bytes 
  clr.dll!Thread::DoExtraWorkForFinalizer()  - 0x4c12 bytes 
  clr.dll!WKS::GCHeap::FinalizerThreadWorker()  + 0x8b bytes 
  clr.dll!Thread::DoExtraWorkForFinalizer()  + 0x3e0ff bytes 
  clr.dll!Thread::ShouldChangeAbortToUnload()  - 0x5f4 bytes 
  clr.dll!Thread::ShouldChangeAbortToUnload()  - 0x539 bytes 
  clr.dll!ManagedThreadBase_NoADTransition()  + 0x35 bytes 
  clr.dll!ManagedThreadBase::FinalizerBase()  + 0xf bytes 
  clr.dll!WKS::GCHeap::FinalizerThreadStart()  + 0xfb bytes 
  clr.dll!Thread::intermediateThreadProc()  + 0x48 bytes 
  kernel32.dll!@BaseThreadInitThunk@12()  + 0x12 bytes 
  ntdll.dll!___RtlUserThreadStart@8()  + 0x27 bytes 
  ntdll.dll!__RtlUserThreadStart@8()  + 0x1b bytes

В таком случае COM-объект освобождается прямо в контексте Finalizer Thread, что, понятное дело, может привести к проблемам синхронизации, а то и вовсе катастрофой, если код оъекта был выгружен из памяти!

Последний случай - поток работает, в нем инициализирован апартмент, но он не обрабатывает асинхронные сообщения, Finalizer Thread рано или поздно подвисает...

Какие выводы можно сделать из всего этого?

CLR пытается быть a good COM citizen и выполняет автоматический маршалинг вызовов в нужные контексты;
из-за специфики среды выполнения разрушение RCW происходит в выделенном потоке, поэтому во время этой операции за кадром выполняется множество действий, которые могут привести к блокировкам;
уничтожением RCW Finalizer Thread занимается уже после того, как были вызваны методы Finalize объектов в соответствующей очереди, поэтому во время вызова Finalize можно пользоваться RCW, но очень нежелательно (блокировки, заваленные вызовы QueryInterface если tlb не зарегистрирована и т.д.);
блокировать поток желательно вызовом CoWaitForMultipleHandles;
Избегать передачи COM-объектов из потоков, в которых нет работающего цикла сообщений!

Advanced C++ and .NET interop

2010-12-07T20:03:00.001+02:00

В этой статье речь пойдет о проблемах использования элементов управления WinForms из нативного приложения, MFC например.

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

Движением фокуса в контейнерах WinForms занимается пачка методов, самый важный из которых - ContainerControl::ProcessTabKey. Давайте выясним каким образом поток выполнения попадает в этот метод:

> WinFormsMFCHost.exe!WinFormsMFCHost::SampleForm::ProcessTabKey(bool forward = true) Line 48 C++
  System.Windows.Forms.dll!System.Windows.Forms.ContainerControl.ProcessDialogKey(System.Windows.Forms.Keys keyData = LButton | Back) Line 1141 + 0x19 bytes C#
  System.Windows.Forms.dll!System.Windows.Forms.Form.ProcessDialogKey(System.Windows.Forms.Keys keyData) Line 5245 + 0x9 bytes C#
  WinFormsMFCHost.exe!WinFormsMFCHost::SampleForm::ProcessDialogKey(System::Windows::Forms::Keys keyData = System::Windows::Forms::Keys::Tab) Line 43 + 0xb bytes C++
  System.Windows.Forms.dll!System.Windows.Forms.ContainerControl.ProcessDialogKey(System.Windows.Forms.Keys keyData) Line 1152 + 0x16 bytes C#
  WinFormsMFCHost.exe!WinFormsMFCHost::SampleControl::ProcessDialogKey(System::Windows::Forms::Keys keyData = System::Windows::Forms::Keys::Tab) Line 42 + 0xb bytes C++
  System.Windows.Forms.dll!System.Windows.Forms.Control.ProcessDialogKey(System.Windows.Forms.Keys keyData) Line 10170 + 0x14 bytes C#
  System.Windows.Forms.dll!System.Windows.Forms.Control.PreProcessMessage(ref System.Windows.Forms.Message msg) Line 9864 + 0xf bytes C#
  System.Windows.Forms.dll!System.Windows.Forms.Control.PreProcessControlMessageInternal(System.Windows.Forms.Control target = {System.Windows.Forms.TabControl}, ref System.Windows.Forms.Message msg = {System.Windows.Forms.Message}) Line 9949 + 0x10 bytes C#
  System.Windows.Forms.dll!System.Windows.Forms.Application.ThreadContext.PreTranslateMessage(ref System.Windows.Forms.NativeMethods.MSG msg = {System.Windows.Forms.NativeMethods.MSG}) Line 3618 + 0xb bytes C#
  System.Windows.Forms.dll!System.Windows.Forms.Application.ThreadContext.LocalModalMessageLoop(System.Windows.Forms.Form form = {WinFormsMFCHost.SampleForm}) Line 3503 + 0xb bytes C#
  System.Windows.Forms.dll!System.Windows.Forms.Application.ThreadContext.RunMessageLoopInner(int reason = 0x00000004, System.Windows.Forms.ApplicationContext context = {System.Windows.Forms.Application.ModalApplicationContext}) Line 3429 + 0xd bytes C#
  System.Windows.Forms.dll!System.Windows.Forms.Application.ThreadContext.RunMessageLoop(int reason, System.Windows.Forms.ApplicationContext context) Line 3306 + 0xa bytes C#
  System.Windows.Forms.dll!System.Windows.Forms.Application.RunDialog(System.Windows.Forms.Form form) Line 1517 + 0x2b bytes C#
  System.Windows.Forms.dll!System.Windows.Forms.Form.ShowDialog(System.Windows.Forms.IWin32Window owner) Line 6122 + 0x8 bytes C#
  System.Windows.Forms.dll!System.Windows.Forms.Form.ShowDialog() Line 6022 + 0x7 bytes C#

Самая важная часть стека выделена красным. .NET использует концепцию пре трансляции сообщений. Она очень похожа на механизм, который используется в MFC. Суть его простая - в цикле сообщений перед их диспатчеризацией выполняется CWnd::WalkPreTranslateTree активного окна, которая в свою очередь вызывает CWnd::PreTranslateMessage. Сообщения можно съедать, изменять и вообще выполнять любую другую логику. Например - управлять фокусом. Логично ведь - элемент управления сам не может знать как ему перемещать фокус внутри контейнера (форма, диалог - не важно). И вот тут к нам пришла засада - если цикл сообщений крутит не .NET, а MFC например, - ThreadContext::PreTranslateMessage не будет вызван, соответственно все необходимые методы далее по стеку. Фокус не перемещается.

И вот я задался вопросом - как же работают программы типа Visual Studio, Excel, Word, Outlook, где .NET интегрирован и работает нормально - показывает формы, диалоги, используются пользовательские элементы управления (наследники UserControl). Ответ я нашел в исходниках WinForms после длительного хардфакинга в рефлекторе и отладчике. Все банально - WinForms использует скрытый интерфейс для взаимодействия с хост-приложением. Этот интерфейс позволяет проталкивать необходимый вызов ThreadContext::PreTranslateMessage.

Посмотрим что происходит при вызове метода Show формы:

> System.Windows.Forms.dll!System.Windows.Forms.Application.ThreadContext.ComponentManager.get() Line 2549 + 0x17 bytes C#
  System.Windows.Forms.dll!System.Windows.Forms.Application.ThreadContext.FormActivated(bool activate) Line 2975 + 0x7 bytes C#
  System.Windows.Forms.dll!System.Windows.Forms.Form.WmActivate(ref System.Windows.Forms.Message m = {System.Windows.Forms.Message}) Line 6842 + 0x2d bytes C#
  System.Windows.Forms.dll!System.Windows.Forms.Form.WndProc(ref System.Windows.Forms.Message m) Line 7433 C#
  System.Windows.Forms.dll!System.Windows.Forms.Control.ControlNativeWindow.OnMessage(ref System.Windows.Forms.Message m) Line 14109 + 0xe bytes C#
  System.Windows.Forms.dll!System.Windows.Forms.Control.ControlNativeWindow.WndProc(ref System.Windows.Forms.Message m) Line 14164 + 0xb bytes C#
  System.Windows.Forms.dll!System.Windows.Forms.NativeWindow.DebuggableCallback(System.IntPtr hWnd, int msg = 0x00000006, System.IntPtr wparam, System.IntPtr lparam) Line 779 + 0xe bytes C#
  user32.dll!_InternalCallWinProc@20()  + 0x23 bytes 
  user32.dll!_UserCallWinProcCheckWow@32()  + 0xb3 bytes 
  user32.dll!_DispatchClientMessage@20()  + 0x4b bytes 
  user32.dll!___fnDWORD@4()  + 0x24 bytes 
  ntdll.dll!_KiUserCallbackDispatcher@12()  + 0x2e bytes 
  user32.dll!_NtUserShowWindow@8()  + 0xc bytes 
  [Managed to Native Transition] 
  System.Windows.Forms.dll!System.Windows.Forms.Control.SetVisibleCore(bool value = true) Line 11762 + 0x46f bytes C#
  System.Windows.Forms.dll!System.Windows.Forms.Form.SetVisibleCore(bool value = true) Line 2684 C#
  System.Windows.Forms.dll!System.Windows.Forms.Control.Show() Line 12059 + 0x10 bytes C#

ComponentManager - WTF? Код:

internal UnsafeNativeMethods.IMsoComponentManager ComponentManager { 
      get {
 
         Debug.WriteLineIf(CompModSwitches.MSOComponentManager.TraceInfo, "Application.ComponentManager.Get:"); 
 
         if (componentManager == null) { 
 
            // The CLR is a good COM citizen and will pump messages when things are waiting.
            // This is nice; it keeps the world responsive.  But, it is also very hard for
            // us because most of the code below causes waits, and the likelihood that 
            // a message will come in and need a component manager is very high.  Recursing
            // here is very very bad, and will almost certainly lead to application failure 
            // later on as we come out of the recursion.  So, we guard it here and return 
            // null.  EVERYONE who accesses the component manager must handle a NULL return!
            // 
            if (fetchingComponentManager) {
                  return null;
            }
 
            fetchingComponentManager = true;
            try { 
                  UnsafeNativeMethods.IMsoComponentManager msocm = null; 
                  Application.OleRequired();
 
                  // Attempt to obtain the Host Application MSOComponentManager
                  //
                  IntPtr msgFilterPtr = (IntPtr)0;
 
                  if (NativeMethods.Succeeded(UnsafeNativeMethods.CoRegisterMessageFilter(NativeMethods.NullHandleRef, ref msgFilterPtr)) && msgFilterPtr != (IntPtr)0) {
 
                     IntPtr dummy = (IntPtr)0; 
                     UnsafeNativeMethods.CoRegisterMessageFilter(new HandleRef(null, msgFilterPtr), ref dummy);
 
                     object msgFilterObj = Marshal.GetObjectForIUnknown(msgFilterPtr);
                     Marshal.Release(msgFilterPtr);
 
                     UnsafeNativeMethods.IOleServiceProvider sp = msgFilterObj as UnsafeNativeMethods.IOleServiceProvider; 
                     if (sp != null) {
                        try { 
                              IntPtr retval = IntPtr.Zero; 
 
                              // PERF ALERT ([....]): Using typeof() of COM object spins up COM at JIT time. 
                              // Guid compModGuid = typeof(UnsafeNativeMethods.SMsoComponentManager).GUID;
                              //
                              Guid compModGuid = new Guid("000C060B-0000-0000-C000-000000000046");
                              Guid iid = new Guid("{000C0601-0000-0000-C000-000000000046}"); 
                              int hr = sp.QueryService(
                                             ref compModGuid, 
                                             ref iid, 
                                             out retval);
 
                              if (NativeMethods.Succeeded(hr) && retval != IntPtr.Zero) {
 
                                 // Now query for hte message filter.
 
                                 IntPtr pmsocm;
 
                                 try { 
                                    Guid IID_IMsoComponentManager = typeof(UnsafeNativeMethods.IMsoComponentManager).GUID;
                                    hr = Marshal.QueryInterface(retval, ref IID_IMsoComponentManager, out pmsocm); 
                                 }
                                 finally {
                                    Marshal.Release(retval);
                                 } 
 
                                 if (NativeMethods.Succeeded(hr) && pmsocm != IntPtr.Zero) { 
 
                                    // Ok, we have a native component manager.  Hand this over to
                                    // our broker object to get a proxy we can use 
                                    try {
                                          msocm = ComponentManagerBroker.GetComponentManager(pmsocm);
                                    }
                                    finally { 
                                          Marshal.Release(pmsocm);
                                    } 
                                 } 
 
                                 if (msocm != null) { 
 
                                    // If the resulting service is the same pUnk as the
                                    // message filter (a common implementation technique),
                                    // then we want to null msgFilterObj at this point so 
                                    // we don't call RelaseComObject on it below.  That would
                                    // also release the RCW for the component manager pointer. 
                                    if (msgFilterPtr == retval) { 
                                          msgFilterObj = null;
                                    } 
 
                                    externalComponentManager = true;
                                    Debug.WriteLineIf(CompModSwitches.MSOComponentManager.TraceInfo, "Using MSO Component manager");
 
                                    // Now attach app domain unload events so we can
                                    // detect when we need to revoke our component 
                                    // 
                                    AppDomain.CurrentDomain.DomainUnload += new EventHandler(OnDomainUnload);
                                    AppDomain.CurrentDomain.ProcessExit += new EventHandler(OnDomainUnload); 
                                 }
                              }
                        }
                        catch { 
                        }
                     } 
 
                     if (msgFilterObj != null && Marshal.IsComObject(msgFilterObj)) {
                        Marshal.ReleaseComObject(msgFilterObj); 
                     }
                  }
 
                  // Otherwise, we implement component manager ourselves 
                  //
                  if (msocm == null) { 
                     msocm = new ComponentManager(); 
                     externalComponentManager = false;
 
                     // We must also store this back into the message filter for others
                     // to use.
                     //
                     // 
                     Debug.WriteLineIf(CompModSwitches.MSOComponentManager.TraceInfo, "Using our own component manager");
                  } 
 
                  if (msocm != null && componentID == INVALID_ID) {
                     // Finally, if we got a compnent manager, register ourselves with it. 
                     //
                     Debug.WriteLineIf(CompModSwitches.MSOComponentManager.TraceInfo, "Registering MSO component with the component manager");
                     NativeMethods.MSOCRINFOSTRUCT info = new NativeMethods.MSOCRINFOSTRUCT();
                     info.cbSize = Marshal.SizeOf(typeof(NativeMethods.MSOCRINFOSTRUCT)); 
                     info.uIdleTimeInterval = 0;
                     info.grfcrf = NativeMethods.MSOCM.msocrfPreTranslateAll | NativeMethods.MSOCM.msocrfNeedIdleTime; 
                     info.grfcadvf = NativeMethods.MSOCM.msocadvfModal; 
 
                     IntPtr localComponentID; 
                     bool result = msocm.FRegisterComponent(this, info, out localComponentID);
                     componentID = unchecked((int)(long)localComponentID);
                     Debug.Assert(componentID != INVALID_ID, "Our ID sentinel was returned as a valid ID");
 
                     if (result && !(msocm is ComponentManager)) {
                        messageLoopCount++; 
                     } 
 
                     Debug.Assert(result, "Failed to register WindowsForms with the ComponentManager -- DoEvents and modal dialogs will be broken. size: " + info.cbSize); 
                     Debug.WriteLineIf(CompModSwitches.MSOComponentManager.TraceInfo, "ComponentManager.FRegisterComponent returned " + result.ToString());
                     Debug.WriteLineIf(CompModSwitches.MSOComponentManager.TraceInfo, "ComponentManager.FRegisterComponent assigned a componentID == [0x" + Convert.ToString(componentID, 16) + "]");
                     componentManager = msocm;
                  } 
            }
            finally { 
                  fetchingComponentManager = false; 
            }
         } 
 
         return componentManager;
      }
}

Нихуя себе! Сказал я себе. Этот метод выполняет следующие действия:

Дважды вызывает CoRegisterMessageFilter чтобы получить реализацию IMessageFilter для текущего потока;
Запрашивает у полученного объекта интерфейс IOleServiceProvider, который на самом деле - IServiceProvider, объявление находится в файле ServProv.h;

Вызывает метод QueryService для получения реализации необходимой службы - IMsoComponentManager.

static const GUID SERVICEID_MSO_COMPONENT_MANAGER = { 0x000C060B, 0x0000, 0x0000, { 0xC0, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x46 } };

Если действия выше неудачны - используется своя реализация IMsoComponentManager;
Далее ThreadContext регистрирует себя в менеджере с помощью метода FRegisterComponent (ThreadContext поддерживает интерфейс IMsoComponent).

Задача стала ясна - реализовать COM-объект с необходимыми интерфейсами, зарегистрировать его вызовом CoRegisterMessageFilter и проталкивать сообщения из CWinThread::PreTranslateMessage во все активные IMsoComponent вызывая IMsoComponent::FPreTranslateMessage. На самом деле все чуть сложней - активный компонент максимум один, но зато есть еще так называемый tracking компонент. Например при открытии конекстного меню ThreadContext становится tracking, а при закрытии возвращается в обычное состояние. При этом он не обязательно будет активным.

Погуглив на тему IMsoComponentManager и IMsoComponent, я не нашел никакой полезной информации. Ни tlb, ни idl. С какой-то попытки наткнулся на файл msoci.h в неком SVN репозитарии и выяснил, что он является частью Visual Studio 2010 SDK и лежит в папке C:\Program Files\Microsoft Visual Studio 2010 SDK\VisualStudioIntegration\Common\Inc\office10. Очень порадовала документация к методам. Ведь она там есть! Причем детальное описание.

Собственно, реализация IMsoComponentManager:

#pragma once
#include "objidl.h"
#include <ServProv.h>
#include <msoci.h>
#include <unordered_map>
 
class CCOMMessageFilter : public IMessageFilter,
                          public IServiceProvider,
                          public IMsoComponentManager
{
 
public:
   CCOMMessageFilter();
   virtual ~CCOMMessageFilter();
 
public:
   BOOL PreTranslateMessage(MSG *pMsg);
 
public:
   // IUnknown
   HRESULT STDMETHODCALLTYPE QueryInterface(REFIID riid, LPVOID *ppvObj);
   ULONG STDMETHODCALLTYPE AddRef();
   ULONG STDMETHODCALLTYPE Release();
   
private:
   // IMessageFilter
   DWORD STDMETHODCALLTYPE HandleInComingCall(DWORD dwCallType, HTASK htaskCaller, DWORD dwTickCount, LPINTERFACEINFO lpInterfaceInfo);
   DWORD STDMETHODCALLTYPE RetryRejectedCall(HTASK htaskCallee, DWORD dwTickCount, DWORD dwRejectType);
   DWORD STDMETHODCALLTYPE MessagePending(HTASK htaskCallee, DWORD dwTickCount, DWORD dwPendingType);
 
private:
   // IServiceProvider
   HRESULT STDMETHODCALLTYPE QueryService(REFGUID guidService, REFIID riid, LPVOID *ppvObj);
 
private:
   // IMsoComponentManager
   BOOL STDMETHODCALLTYPE FDebugMessage(HMSOINST hinst, UINT message, WPARAM wParam, LPARAM lParam);
   BOOL STDMETHODCALLTYPE FRegisterComponent(IMsoComponent *piComponent, const MSOCRINFO *pcrinfo, DWORD_PTR *pdwComponentID);
   BOOL STDMETHODCALLTYPE FRevokeComponent(DWORD_PTR dwComponentID);
   BOOL STDMETHODCALLTYPE FUpdateComponentRegistration(DWORD_PTR dwComponentID, const MSOCRINFO *pcrinfo);
   BOOL STDMETHODCALLTYPE FOnComponentActivate(DWORD_PTR dwComponentID);
   BOOL STDMETHODCALLTYPE FSetTrackingComponent(DWORD dwComponentID, ULONG grftrack);
   void STDMETHODCALLTYPE OnComponentEnterState(DWORD_PTR dwComponentID, ULONG uStateID, ULONG uContext, ULONG cpicmExclude, IMsoComponentManager **rgpicmExclude, DWORD dwReserved);
   BOOL STDMETHODCALLTYPE FOnComponentExitState(DWORD_PTR dwComponentID, ULONG uStateID, ULONG uContext, ULONG cpicmExclude, IMsoComponentManager **rgpicmExclude);
   BOOL STDMETHODCALLTYPE FInState(DWORD uStateID, LPVOID pvoid);
   BOOL STDMETHODCALLTYPE FContinueIdle();
   BOOL STDMETHODCALLTYPE FPushMessageLoop(DWORD_PTR dwComponentID, ULONG uReason, void *pvLoopData);
   BOOL STDMETHODCALLTYPE FCreateSubComponentManager(IUnknown *pUnkOuter, IUnknown *pUnkServProv, REFIID riid, LPVOID *ppvObj);
   BOOL STDMETHODCALLTYPE FGetParentComponentManager(IMsoComponentManager **ppicm);
   BOOL STDMETHODCALLTYPE FGetActiveComponent(DWORD dwgac, IMsoComponent **ppic, MSOCRINFO *pcrinfo, DWORD dwReserved);
 
private:
   ULONG _refCount;   
 
   typedef CComPtr<IMsoComponent> IMsoComponentPtr;
   struct MsoComponentRegistration { IMsoComponentPtr ComponentPtr; MSOCRINFO Info; };
   typedef std::tr1::unordered_map<DWORD_PTR, MsoComponentRegistration> component_registrations_t;
   typedef std::tr1::unordered_map<DWORD_PTR, IMsoComponentPtr> tracking_components_t;
 
   DWORD_PTR _nextComponentId;
   DWORD_PTR _activeComponentId;
   IMsoComponentPtr _activeComponentPtr;
   component_registrations_t _components;
   tracking_components_t _tracking;
   bool _trackingIteration;
   tracking_components_t _track;
   tracking_components_t _untrack;
 
};

#include "stdafx.h"
#include "COMMessageFilter.h"
#define INIT_MSO_GUIDS
#include <msoguids.h>
 
CCOMMessageFilter::CCOMMessageFilter() : _refCount(0), _nextComponentId(0), _activeComponentId(-1), _trackingIteration(false) {
}
 
/*virtual*/ CCOMMessageFilter::~CCOMMessageFilter() {
}
 
BOOL CCOMMessageFilter::PreTranslateMessage(MSG *pMsg) {
   BOOL bRet = FALSE;
   
   if (!_tracking.empty()) {
      // Tracking ones first
      _trackingIteration = true;
      for (tracking_components_t::const_reverse_iterator pos = _tracking.rbegin(); pos != _tracking.rend(); ++pos) {
         bRet = bRet || pos->second->FPreTranslateMessage(pMsg);
      }
      _trackingIteration = false;
 
      // Insert tracked components
      _tracking.insert(_track.begin(), _track.end());
      _track.clear();
 
      // Delete untracked components
      for (tracking_components_t::const_iterator pos = _untrack.begin(); pos != _untrack.end(); ++pos) {
         _tracking.erase(pos->first);
      }
      _untrack.clear();
 
      if (bRet)
         return(bRet);
   }
 
   // Active one
   if (_activeComponentPtr)
      bRet = _activeComponentPtr->FPreTranslateMessage(pMsg);         
 
   return(bRet);
}
 
HRESULT STDMETHODCALLTYPE CCOMMessageFilter::QueryInterface(REFIID riid, LPVOID *ppvObj) {
   if (!ppvObj)
      return(E_POINTER);
 
   if (riid == IID_IUnknown) {
      *ppvObj = static_cast<IUnknown *>(static_cast<IMessageFilter *>(this));
   }
   else if (riid == IID_IMessageFilter) {
      *ppvObj = static_cast<IMessageFilter *>(this);
   }
   else if (riid == IID_IServiceProvider) {
      *ppvObj = static_cast<IServiceProvider *>(this);
   }
   else if (riid == IID_IMsoComponentManager) {
      *ppvObj = static_cast<IMsoComponentManager *>(this);
   }
   else {
      *ppvObj = NULL;
      return(E_NOINTERFACE);
   }
 
   AddRef();
   return(S_OK);
}
 
ULONG STDMETHODCALLTYPE CCOMMessageFilter::AddRef() {
   return(InterlockedIncrement(&_refCount));
}
 
ULONG STDMETHODCALLTYPE CCOMMessageFilter::Release() {
   const ULONG count = InterlockedDecrement(&_refCount);
   if (count == 0)
      delete this;
   return(count);
}
 
// IMessageFilter
DWORD STDMETHODCALLTYPE CCOMMessageFilter::HandleInComingCall(DWORD dwCallType, HTASK htaskCaller, DWORD dwTickCount, LPINTERFACEINFO lpInterfaceInfo) {
   return(SERVERCALL_RETRYLATER);
}
 
DWORD STDMETHODCALLTYPE CCOMMessageFilter::RetryRejectedCall(HTASK htaskCallee, DWORD dwTickCount, DWORD dwRejectType) {
   return(100);
}
 
DWORD STDMETHODCALLTYPE CCOMMessageFilter::MessagePending(HTASK htaskCallee, DWORD dwTickCount, DWORD dwPendingType) {
   return(PENDINGMSG_WAITNOPROCESS);
}
 
// IOleServiceProvider
HRESULT STDMETHODCALLTYPE CCOMMessageFilter::QueryService(REFGUID guidService, REFIID riid, LPVOID *ppvObj) {
   TRACE(_T("CCOMMessageFilter::QueryService\n"));
 
   if (!ppvObj)
      return(E_POINTER);
 
   *ppvObj = NULL;
 
   static const GUID SERVICEID_MSO_COMPONENT_MANAGER = { 0x000C060B, 0x0000, 0x0000, { 0xC0, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x46 } };
   if (guidService == SERVICEID_MSO_COMPONENT_MANAGER) {
      return(QueryInterface(riid, ppvObj));
   }
   return(E_NOINTERFACE);
}
 
BOOL STDMETHODCALLTYPE CCOMMessageFilter::FDebugMessage(HMSOINST hinst, UINT message, WPARAM wParam, LPARAM lParam) {
   TRACE(_T("CCOMMessageFilter::FDebugMessage\n"));
 
   return(TRUE);
}
 
BOOL STDMETHODCALLTYPE CCOMMessageFilter::FRegisterComponent(IMsoComponent *piComponent, const MSOCRINFO *pcrinfo, DWORD_PTR *pdwComponentID) {
   TRACE(_T("CCOMMessageFilter::FRegisterComponent\n"));
 
   if (!piComponent)
      return(E_POINTER);
   if (!pcrinfo)
      return(E_POINTER);
   if (!pdwComponentID)
      return(E_POINTER);
   
   *pdwComponentID = _nextComponentId++;
   const MsoComponentRegistration reg = { piComponent, *pcrinfo };
   _components[*pdwComponentID] = reg;
   
   return(TRUE);
}
 
BOOL STDMETHODCALLTYPE CCOMMessageFilter::FRevokeComponent(DWORD_PTR dwComponentID) {
   TRACE(_T("CCOMMessageFilter::FRevokeComponent\n"));
   
   _components.erase(dwComponentID);
   if (_trackingIteration) {
      const tracking_components_t::const_iterator pos = _tracking.find(dwComponentID);
      if (pos != _tracking.end())
         _untrack.insert(*pos);
   }
   else
      _tracking.erase(dwComponentID);
 
   if (dwComponentID == _activeComponentId) {
      _activeComponentId = -1;
      _activeComponentPtr.Release();
   }
 
   return(TRUE);
}
 
BOOL STDMETHODCALLTYPE CCOMMessageFilter::FUpdateComponentRegistration(DWORD_PTR dwComponentID, const MSOCRINFO *pcrinfo) {
   TRACE(_T("CCOMMessageFilter::FUpdateComponentRegistration\n"));
 
   if (!pcrinfo)
      return(E_POINTER);
 
   const component_registrations_t::iterator pos = _components.find(dwComponentID);
   if (pos != _components.end()) {
      pos->second.Info = *pcrinfo;
      return(TRUE);
   }
 
   return(FALSE);
}
 
BOOL STDMETHODCALLTYPE CCOMMessageFilter::FOnComponentActivate(DWORD_PTR dwComponentID) {
   TRACE(_T("CCOMMessageFilter::FOnComponentActivate\n"));
 
   const component_registrations_t::iterator pos = _components.find(dwComponentID);
   if (pos != _components.end()) {
      _activeComponentId = pos->first;
      _activeComponentPtr = pos->second.ComponentPtr;
      return(TRUE);
   }
 
   return(FALSE);
}
 
BOOL STDMETHODCALLTYPE CCOMMessageFilter::FSetTrackingComponent(DWORD dwComponentID, ULONG grftrack) {
   TRACE(_T("CCOMMessageFilter::FSetTrackingComponent\n"));
 
   const BOOL bTrack = grftrack;
   if (!bTrack) {
      if (_trackingIteration) {
         const tracking_components_t::const_iterator pos = _tracking.find(dwComponentID);
         if (pos != _tracking.end())
            _untrack.insert(*pos);
         else
            _track.erase(dwComponentID);
      }
      else
         _tracking.erase(dwComponentID);
 
      return(TRUE);
   }
 
   const component_registrations_t::iterator pos = _components.find(dwComponentID);
   if (pos != _components.end()) {
      if (_trackingIteration)
         _track[dwComponentID] = pos->second.ComponentPtr;
      else
         _tracking[dwComponentID] = pos->second.ComponentPtr;
 
      return(TRUE);
   }
 
   return(FALSE);
}
 
void STDMETHODCALLTYPE CCOMMessageFilter::OnComponentEnterState(DWORD_PTR dwComponentID, ULONG uStateID, ULONG uContext, ULONG cpicmExclude, IMsoComponentManager **rgpicmExclude, DWORD dwReserved) {
   TRACE(_T("CCOMMessageFilter::OnComponentEnterState\n"));
}
 
BOOL STDMETHODCALLTYPE CCOMMessageFilter::FOnComponentExitState(DWORD_PTR dwComponentID, ULONG uStateID, ULONG uContext, ULONG cpicmExclude, IMsoComponentManager **rgpicmExclude) {
   TRACE(_T("CCOMMessageFilter::FOnComponentExitState\n"));
   return(TRUE);
}
 
BOOL STDMETHODCALLTYPE CCOMMessageFilter::FInState(DWORD uStateID, LPVOID pvoid) {
   TRACE(_T("CCOMMessageFilter::FInState\n"));
   return(TRUE);
}
 
BOOL STDMETHODCALLTYPE CCOMMessageFilter::FContinueIdle() {
   TRACE(_T("CCOMMessageFilter::FContinueIdle\n"));
   return(TRUE);
}
 
BOOL STDMETHODCALLTYPE CCOMMessageFilter::FPushMessageLoop(DWORD_PTR dwComponentID, ULONG uReason, void *pvLoopData) {
   TRACE(_T("CCOMMessageFilter::FPushMessageLoop\n"));
   return(FALSE);
}
 
BOOL STDMETHODCALLTYPE CCOMMessageFilter::FCreateSubComponentManager(IUnknown *pUnkOuter, IUnknown *pUnkServProv, REFIID riid, LPVOID *ppvObj) {
   TRACE(_T("CCOMMessageFilter::FCreateSubComponentManager\n"));
 
   if (!ppvObj)
      return(E_POINTER);
 
   *ppvObj = NULL;
 
   return(FALSE);
}
 
BOOL STDMETHODCALLTYPE CCOMMessageFilter::FGetParentComponentManager(IMsoComponentManager **ppicm) {
   TRACE(_T("CCOMMessageFilter::FGetParentComponentManager\n"));
 
   if (!ppicm)
      return(E_POINTER);
 
   *ppicm = NULL;
 
   return(FALSE);
}
 
BOOL STDMETHODCALLTYPE CCOMMessageFilter::FGetActiveComponent(DWORD dwgac, IMsoComponent **ppic, MSOCRINFO *pcrinfo, DWORD dwReserved) {
   TRACE(_T("CCOMMessageFilter::FGetActiveComponent\n"));
 
   if (ppic)
      *ppic = NULL;
 
   DWORD_PTR componentId = -1;
 
   if (dwgac == msogacTracking || dwgac == msogacTrackingOrActive) {
      if (!_tracking.empty()) {
         componentId = _tracking.rbegin()->first;
      }
   }
   if (componentId == -1 && (dwgac == msogacActive || dwgac == msogacTrackingOrActive)) {
      componentId = _activeComponentId;
   }
 
    const component_registrations_t::iterator pos = _components.find(componentId);
    if (pos != _components.end()) {
       MsoComponentRegistration &reg = pos->second;
       if (pcrinfo)
         *pcrinfo = reg.Info;
       if (ppic)
         reg.ComponentPtr.CopyTo(ppic);
       return(TRUE);
    }
 
   return(FALSE);
}

Использование:

/*virtual*/ BOOL CWinFormsMFCHostApp::PreTranslateMessage(MSG *pMsg) {
   const BOOL bRet = m_pComponentManager->PreTranslateMessage(pMsg);
   if (bRet)
      return(bRet);
 
   return(__super::PreTranslateMessage(pMsg));
}

Инициализация:

/*virtual*/ BOOL CWinFormsMFCHostApp::InitInstance() {
   INITCOMMONCONTROLSEX InitCtrls;
   InitCtrls.dwSize = sizeof(InitCtrls);
   InitCtrls.dwICC = ICC_WIN95_CLASSES;
   InitCommonControlsEx(&InitCtrls);
 
   __super::InitInstance();
 
   if (!AfxOleInit()) {
      AfxMessageBox(IDP_OLE_INIT_FAILED);
      return(FALSE);
   }
 
   AfxEnableControlContainer();
 
   m_pComponentManager = new CCOMMessageFilter();
   m_pComponentManager->AddRef();
   CoRegisterMessageFilter(m_pComponentManager, NULL);

В результате получаем рабочую во всех смыслах .NET форму.

Я, кстати, удивился, что контекстное меню продолжает нормально работать при отсутствии управляемого цикла сообщений. Эти гады, оказалось, проверяют на наличие цикла сообщений (а эта проверка, кстати, лезет в ComponentManager), а если его нет - создают хук, отправляя все пойманные сообщения в ThreadContext::PreTranslateMessage!

Microsoft not only eats it's own dogfood, but sometimes devours it. Not even giving a chance to taste...

Run tlbexp from post build event

2010-12-02T19:36:00.001+02:00

Долго искал, как в Visual Studio 2010 безопасно вызвать tlbexp.exe, regasm.exe или любую другую утилиту .NET Framework SDK. Безопасно - без хардкода абсолютного пути! Решение нашлось:

"$(FrameworkSdkDir)\bin\NETFX 4.0 Tools\tlbexp" $(TargetPath) /out:$(SolutionDir)\$(ConfigurationName)\$(TargetName).tlb

Стоит также обратить внимание на следующие перменные:

$(WindowsSdkDir)
$(WindowsSdkMSBuildTools)
$(WindowsSdkNetFx35ToolsDir)
$(WindowsSdkNetFx40ToolsDir)
$(WindowsSDKVersionOverride)
$(FrameworkSDKRoot)
$(SDK35ToolsPath)
$(SDK40ToolsPath)

Ergonomic chairs in Kiev

2010-10-31T17:31:00.002+02:00

Недавно занялся поиском эргономичного кресла для дома. На работе у меня Hermal Miller Aeron, очень удобное кресло. Можно часами сидеть, дискомфорта не вызывает.

Herman Miller
Я нашел несколько мест, где можно приобрести кресла этой фирмы:
1. DenzaWorkspace
  Здесь можно заказать кресла Herman Miller, но опробовать их, вроди, ~~нет возможности~~ можно у них в офисе, наличие уточняйте. Есть конструктор кресел!
2. Лига-Нова
  С недавнего времени тоже занимается (upd: уже не занимается, upd: они просто перепродавали кресла от Denza) продажей кресел Herman Miller, Aeron и Mira можно опробовать в магазине "Крісла Стільці Столи" по адресу Украина, 01011, г. Киев, б-р Леси Украинки, 34 , тел.: (044) 461-91-91.
3. MACUser в Харькове
  Свершилось чудо! Сегодня на склад компании macuser.in.ua прибыли долгожданные эргономичные офисные кресела Herman Miller.
А вот сегодня я нашел место, где можно посидеть во всех замечательных креслах Herman Miller - Aeron, Embody, Mirra, Celle. Это Домосфера по адресу Столичное шоссе 101, тел.: (044) 252-70-94. После входа (1-й этаж) держаться правой стороны, кресла тяжело будет не заметить.

Стоимость у нас - 2000+/-400 у.е. в зависимости от модели.
Steel Case
Интернет прям заполнен сравнениями их флагмана Leap с Aeron-ом, написано, что исходя из иследований оно лучше.

Заказать или приобрести можно в компании Office Solutions по адресу ул. Николая Гринченко, 4 03038 Киев, Украина, тел: +38 (044) 459-02-90. Там же можно опробовать много моделей. Я посидел на всем доступном, Leap понравился, но его ебаническая цена в евро и оплата по безналу убили всякое желание покупать. Еще и цену озвучили без НДС. Кстати, американские стулья и варианты их исполнения отличаются от европейских, а эта компания работает с европейским производителем продукции.
Другие кресла ебанической стоимости можно поспрашивать в следующих местах:
1. Студия МАТИСС.
2. Студия немецкой мебели.
Есть еще бюджетный вариант немецких ортопедических кресел, которые собираются в Украине:
1. Альтима.