в диалоге "быстрый поиск" есть только одно поле ввода с выпадающим списком истории поиска. рядом с кнопкой комбобокса должна быть пиктограмма метёлки очищающей поле ввода. в windows метла показывается постоянно и адекватно реагирует на нажатие - очищает поле. в linux, метла появляется только при разворачивании комбобокса. нажать её невозможно. обнаружено при административной установке. в неадминистративной не проверялось. winediag: проблемы не обнаружены. установлен ie6. ubuntu 9.04 2.6.28-15-generic gnome -eter-9/5 K+ сетевая через cifs, v 4000.00.11 сборка 16289
Проверить. Обязательно в режиме административном и обычном режиме.
WINE@Etersoft 1.0.11 eter11/eter6 Проблема воспроизводится. Пиктограмма появляется только если выпадающее меню вызвать. И не работает функционал, т.е. не нажимается (по нажатии должна очищаться строка ввода)
1.0.12-eter7.19/14 Пиктограмма появляется только если выпадающее меню вызвать. И работает, если нажав на выпадающее меню, сместить курсор на "метлу" (с зажатой кнопкой мыши).
Откладываем, bugs@ в ближайшее время делать ничего не будет.
Надо проверить на 2.0
*** Bug 6933 has been marked as a duplicate of this bug. ***
Воспроизводится до сих пор. ALTLinux6 stand NX снимок "консультант настроен" WINE@Etersoft Network 2.0.2-eter5/1 (В ответ на comment #0) > в linux, метла появляется только при разворачивании комбобокса. нажать её > невозможно. В точности.
Сделала бутылку wine@eter-2 bottle kons/demo WINE@Etersoft SQL 2.0.2-eter5/1 Здесь демо версия консультанта. Видно краешек метелки (она прячется за кнопкой со стрелкой).
Наблюдается и для wine-pure
Метелка рисуется прямо на поверхности комбобокса, просто в Wine размер Edit'a настолько велик, что видно только правый край метелки. Причем, если попасть на него мышью, то можно очистить поле редактирования. Т.е. тут все впорядке.
Wine всегда растягивает edit до самой кнопки комбобокса, не позволяя пользователю задавать произвольный размер для edit'а
Есть предположение, что WM_WINDOWPOSCHANGED обрабатывается не совсем корректно. Нужно изучить как происходит обработка под Windows.
Created attachment 2530 [details] Тест #1
Для Windows https://bugs.etersoft.ru/attachment.cgi?id=2530 дает следующий результат: got WM_WINDOWPOSCHANGED, pass to old proc got WM_SIZE WM_WINDOWPOSCHANGED has handled got WM_WINDOWPOSCHANGED, pass to old proc got WM_SIZE WM_WINDOWPOSCHANGED has handled ... Т.е. системная оконная процедура для комбобокса посылает WM_SIZE при обработке WM_WINDOWPOSCHANGED. Wine такого не делает, поэтому процедура внутри Консультанта не получает WM_SIZE и, как следствие, не корректирует размер edit'a.
Провел небольшое исследование реакции системной оконной процедуры комбобокса на WM_WINDOWPOSCHANGED. Получилось следующее: при обработке этого сообщения оконная процедура шлет WM_MOVE а затем WM_SIZE, причем такая реакция наблюдается практически для всех испытанных комбинаций флагов в WINDOWPOS struct независимо от того является ли окно скрытым или запрещенным. Изменить эту последовательность можно только установкой SWP_NOCLIENTMOVE и/или SWP_NOCLIENTSIZE.
Created attachment 2533 [details] Тест для просмотра реакции на WM_WINDOWPOSCHANGED
Получается, что решение заключается в замене /* fall through */ --> break; Меня все же несколько смущают комментарии к case WM_WINDOWPOSCHANGED:, а именно /* we should not force repainting on WM_WINDOWPOSCHANGED, it breaks * Z-order based painting. */
(В ответ на comment #22) > Получается, что решение заключается в замене /* fall through */ --> break; Если это не сломает существующих тестов. > Меня все же несколько смущают комментарии к case WM_WINDOWPOSCHANGED:, а именно > /* we should not force repainting on WM_WINDOWPOSCHANGED, it breaks > * Z-order based painting. > */ Этот комментарий был добавлен мной еще во времена Царя Гороха, в этом месте был код отрисовки, и он что-то ломал. В общем этот комментарий к делу не относится.
Отправленный в winehq тест не приняли, так как > It doesn't make much sense to send this message directly. (http://www.winehq.org/pipermail/wine-devel/2012-June/096135.html) Наверное стоит выслать патч с добавленным тестом вместе с исправлением которое убирает todo. (В ответ на comment #23) > (В ответ на comment #22) > > Получается, что решение заключается в замене /* fall through */ --> break; > > Если это не сломает существующих тестов. make combo.ok и make msg.ok выполняются без ошибок. Правда, в msg.c проверялась только test_combobox_messages(). Остальные пришлось отключить, т.к. где-то происходил вызов XRenderCreateLinearGradient() приводящий к ошибке X Window. Думаю можно считать, что это ничего не слоиало.
Сделал тест для winehq. http://www.winehq.org/pipermail/wine-patches/2012-June/115710.html
Подправил тест, отправил вновь. http://www.winehq.org/pipermail/wine-patches/2012-July/115822.html
(В ответ на comment #27) > Подправил тест, отправил вновь. > http://www.winehq.org/pipermail/wine-patches/2012-July/115822.html Тест приняли. Отправил исправление в winehq. Решение оказалось чуть сложнее чем предполагалось ранее. http://www.winehq.org/pipermail/wine-patches/2012-July/115881.html
Патч до сих пор в очереди. Решил добавить еще один тест и отправить вновь. Этот тест показал некорректность отправленного исправления. Тест отправил http://www.winehq.org/pipermail/wine-patches/2012-July/116269.html, работаю над новым вариантом исправления.
Непонятна ситуация когда высота комбобокса устанавливается в оригинальное значение. При этом в последовательности сообщений возникает WM_WINDOWPOSCHANGING источник которого неясен.
Отправил в eterhack.
Сделала новую бутылку wine@eter-2 bottle bugs/44 WINE@Etersoft SQL 2.0.2-eter13/3 с демо-версией , здесь метелка все еще прячется. Для ALTLinux6 в testing лежит версия wine от 25 июля. Можно ли уточнить, в какой именно версии исправление?
(В ответ на comment #42) > Сделала новую бутылку > wine@eter-2 bottle bugs/44 > WINE@Etersoft SQL 2.0.2-eter13/3 > с демо-версией , здесь метелка все еще прячется. > Для ALTLinux6 в testing лежит версия wine от 25 июля. Можно ли уточнить, в > какой именно версии исправление? Сейчас исправление есть только в ветке eterhack (например: WINE@Etersoft SQL 1.5.8/2.0.2-eter17/3). В ветку eter-2.0.0 оно должно попасть при ближайшей синхронизации с WineHQ. Думаю тогда можно будет и проверить.
Чуть откорректировал и отправил в eter-2.0.0. Решение закоммичено. Думаю можно проверять.
Патч появился в eter-2.0.0 (WINE@Etersoft SQL 2.0.2/2.0.1-eter15/4)
Апдейтила бутылку,после чего консультант нее запускается или падает при запуске в bugs/4405 в новой бутылке 4405-1 аналогично. wine CONS.EXE err:usbhub:initialize_usbhub failed to initialize libusb fixme:dc:DeleteDC not deleting busy DC 0x8d8 refcount 2 err:graphics:USER_CheckNotLock BUG: holding USER lock err:graphics:USER_CheckNotLock BUG: holding USER lock fixme:resource:GetGuiResources (0xfc,0): stub wine: Unhandled exception 0x80000003 at address 0x7ef849ec (thread 0034), starting debugger... err:seh:raise_exception Unhandled exception code c0000005 flags 0 addr 0x7ef5883e При повторном запуске-падение. Дистрибутив в порядке-проверила на windows. Создаю багу.8740
Удалила обе бутылки 4405 и 4405-1. Переустановила wine в eter-2.0 создала заново bugs/4405 Не помогло.
Странная проблема,проявляется только если запускать в моей консоли. Установила wine из testing на ALTlinux standNX. Если напрямую на машине запускать - программа нормально запускается, но,видимо,в сборку testing патч,исправляющий метлу, не вошел. Снимок "консультант-метла"
обновила свой локальный реп. 2.0.0 все корректно.
