Bug 448

dlls/user32/message.c

    case WM_CTLCOLOREDIT:
...
        FIXME( "msg %x (%s) not supported yet\n", message, SPY_GetMsgName(message, hwnd) );
        data->count = -1;
        return 0;

Где проявляется эта бага? Что она мешает сделать? 
В функции pack_message подобным образом не реализованы ещё около 20 обработчиков сообщений...

Вроде как при появлении окна печати в 1С 7.7.
Хотелось бы понять, для чего нужно это сообщение, и реализовать его корректно.

Это до сих проявляется у Вики и Ани, сообщение всё то же.
Но я стал думать, что это из-за повреждения памяти, потому что обычным образом воспроизвести проблему нельзя.

trace:loaddll:load_builtin_dll Loaded module L"c:\\windows\\system32\\wineps.drv" : builtin
trace:loaddll:free_modref Unloaded module L"c:\\windows\\system32\\wineps.drv" : builtin
trace:loaddll:load_builtin_dll Loaded module L"c:\\windows\\system32\\wineps.drv" : builtin
trace:loaddll:free_modref Unloaded module L"c:\\windows\\system32\\wineps.drv" : builtin
fixme:msg:pack_message msg 133 (WM_CTLCOLOREDIT) not supported yet
err:win:DefWindowProcW called for other process window 0x20020

Это сообщение появляется при подборе товара по названию в справочнике Номенклатуры (выключенный иерархический список).

Отправляется из функции EDIT_NotifyCtlColor

=>1 0x7ecf830c put_message_in_queue+0x4ac(info=0x34e8b0, reply_size=0x34e88c) [/home/lav/Projects/wine/dlls/user32/message.c:667] in user32 (0x0034e76c)
  2 0x7ecf6edb send_inter_thread_message+0x4b(info=0x34e8b0, res_ptr=0x34e8d8) [/home/lav/Projects/wine/dlls/user32/message.c:2336] in user32 (0x0034e89c)
  3 0x7ecf7d59 SendMessageTimeoutW+0xd9(hwnd=<register ESI not in topmost frame>, msg=0x133, wparam=0x1738, lparam=<register EDI not in topmost frame>, flags=0x0, timeout=0x0, res_ptr=0x34e924) [/home/lav/Projects/wine/dlls/user32/message.c:2426] in user32 (0x0034e8ec)
  4 0x7ecf7e47 SendMessageW+0x37(hwnd=0x20020, msg=0x133, wparam=0x1738, lparam=0x40288) [/home/lav/Projects/wine/dlls/user32/message.c:2506] in user32 (0x0034e92c)
  5 0x7ecd1807 EDIT_WM_Paint+0xe7(es=<register EDI not in topmost frame>, hdc=0x0) [/home/lav/Projects/wine/dlls/user32/edit.c:424] in user32 (0x0034eb2c)

Нужно написать тест, проверяющий последовательность сообщений при рисовании edit:
- обратить внимание на get_app_version() - wine developer list in Nov 1999
- разобраться с выбором	msg = WM_CTLCOLORSTATIC и WM_CTLCOLOREDIT
- уточнить что с /* why do we notify to es->hwndParent, and we send this one to GetParent()? */

"The WM_CTLCOLOREDIT message is never sent between threads."

http://msdn2.microsoft.com/en-us/library/ms672119.aspx
http://dvinogradov.blogspot.com/2007/05/when-edit-control-sends.html

В MSDN написано: "The WM_CTLCOLOREDIT message is never sent between threads." Но в случае, когда родительским окном является Desktop, Wine посылает WM_CTLCOLOREDIT процессу explorer.exe.         

hbrush = (HBRUSH)SendMessageW(GetParent(es->hwndSelf), msg, (WPARAM)hdc, (LPARAM)es->hwndSelf);

Кстати в pack_message обрабатываются сообщения как раз для передачи между процессами, поэтому отсутствие там WM_CTLCOLOREDIT, похоже, не является ошибкой.

Надо еще написать тест для 
/* why do we notify to es->hwndParent, and we send this one to GetParent()? */
и проверить в винде. Для случая, когда смена родителя происходит после создания окна. 

Есть тест для сравнения работы с es->hwndParent и GetParent() в ф-ции EDIT_NotifyCtlColor. В результате получилось, что edit контролу присваивается один из стандартных цветов windows не зависимо от цвета фона родителя (COLOR_WINDOW). Но если родительское окно было изменено а старое удалено, этот цвет в wine отличается от цвета в винде. В этом случае используется es->hwndParent, т.е. обращение к несуществующему окну.
Если же использовать GetParent(), то тест проходит и в винде и в wine.

В общем, можно сделать вывод, что правильнее вариант с GetParent().

Еще есть небольшое замечание. 
Если использовать es->hwndParent то в результате вызова:

hbrush = (HBRUSH)SendMessageW(es->hwndParent, msg, (WPARAM)hdc,  (LPARAM)es->hwndSelf);

hbrush будет 0.
После этого попадаем на:

hbrush = (HBRUSH)DefWindowProcW(es->hwndParent, msg, (WPARAM)hdc, (LPARAM)es->hwndSelf);

и hbrush остается 0.
Если вызывать в DefWindowProcW GetParent(), то значение hbrush будет корректное.

Есть тест на отправку уведомлений родителю от edit контрола. В wine как и в винде все уведомления отсылаются только окну создавшему контрол. Это справедливо также для случая, когда родительское окно уничтожается.

Тесты и патчи на edit контрол, имеющие отношение к теме:

http://www.winehq.org/pipermail/wine-patches/2005-November/022150.html
http://www.winehq.org/pipermail/wine-patches/2001-March/000168.html

В первой ссылке, в варианте до патча в EDIT_NotifyCtlColor не было вызова DefWindowProcW, который для родительского окна из другого процесса дает err.
Также ранее в EDIT_WM_Paint осуществлялась проверка: 

	if (!(brush = EDIT_NotifyCtlColor(es, dc)))
		brush = (HBRUSH)GetStockObject(WHITE_BRUSH);

Без нее в FillRect передается hbrush равный 0.

Единственный побочный эффект этой баги, который удалось обнаружить - серый цвет edit контрола, родителем которого является desktop. В windows же цвет такого контрола - белый.

Сделал патч для фикса и теста. 
Фикс представляет собой небольшой откат 2ca23be50f7bf0fae845f12149975765ab7b2524 коммита. Дело в том что этот коммит добавляет вызов DefWindowProcW в ф-ции EDIT_NotifyCtlColor и удаляет проверку hbrush на 0 в ф-ции EDIT_WM_Paint. Если вернуться к предыдущему варианту, то проблема с обращением к окну другого процесса корректно обрабатывается. Тем более, что этот откат никак не отражается на тесты для edit контрола - все они успешно проходят.

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