fixme:msg:pack_message msg 133 (WM_CTLCOLOREDIT) not supported yet
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 контрола - все они успешно проходят.
Для тех, кто не пользуется багзиллой или не умеет пользоваться групповым редактированием при поиске, закрываем задачи, которые они должны были принять.
