Если свернуть и развернуть окно СБиС++ ЭО, то куда-то пропадает строка состояния. СБиС++ ЭО 2.4.43 buh/sbis/2.4.43 на eterhack WINE@Etersoft SQL 2.0.0-eter2.17/8
Created attachment 2443 [details] Окно до сворачивания
Created attachment 2444 [details] Окно после сворачивания
При запуске с "comctl32=n" проблема частично решается. Ребар не исчезает, но остальное содержимое окна СБИС рисуется так, будто ребара нет (уходит слишком низко). Начал исследование.
(В ответ на comment #3) > При запуске с "comctl32=n" проблема частично решается. Ребар не исчезает, но > остальное содержимое окна СБИС рисуется так, будто ребара нет (уходит слишком > низко). Начал исследование. comctl32 здесь не причём. Такая ненормальная реакция наблюдается только при сворачивании.разворачивании. Растягивание окна ничего не портит.
Проблема есть и при эмулировании рабочего стола. Вероятно она где-то в user32. Похоже, что статусбар и ребар сохраняют свои размеры, но закрываются окном-близнецом. Причем этот близнец имеет неправильные размеры, почему так - пока неясно.
(В ответ на comment #5) > ... и ребар сохраняют свои размеры, но закрываются окном-близнецом. s/закрываются/перекрываются/g
Пытаюсь понять логику изменения размеров проблемных контролов. Сейчас есть предположение, что проблема связана с MDI-Client-окном СБИС. (Это согласуется с тем, что нативная comctl32 не решает проблему).
(В ответ на comment #7) > Пытаюсь понять логику изменения размеров проблемных контролов. Сейчас есть > предположение, что проблема связана с MDI-Client-окном СБИС. (Это согласуется с > тем, что нативная comctl32 не решает проблему). Начал поиск в єтом направлении, пока ситуация не проясняется.
(В ответ на comment #8) > (В ответ на comment #7) > > Пытаюсь понять логику изменения размеров проблемных контролов. Сейчас есть > > предположение, что проблема связана с MDI-Client-окном СБИС. (Это согласуется с > > тем, что нативная comctl32 не решает проблему). > > Начал поиск в єтом направлении, пока ситуация не проясняется. Дополнительный поиск не дал результатов, скорее всего MDI здесь ни причем.
eter-2.0 bugs/8766 Аналогично реагируют все ребары в СБиСе. Есть предположение, что выставляется минимальный размер, заданный при инициализации ребара.
(В ответ на comment #10) > eter-2.0 bugs/8766 > > Аналогично реагируют все ребары в СБиСе. Есть предположение, что выставляется > минимальный размер, заданный при инициализации ребара. А с "comctl32=n" не пробовал? Как всё выглядит?
Продолжаю поиски проблемы.
(В ответ на comment #12) > Продолжаю поиски проблемы. По текущим результатам создается впечатление, что проблема как в user32 так и в comctl32. Причем что именно в юзере - неясно. (Лучше начать с неё сделав comctl32=n).
Работаю над задачей.
Анализирую последовательности оконных сообщений. Пока ничего интересного не нашел.
Всё-же виноват не ребар. Его размеры не меняются, просто он опускается слишком низко, и поэтому видно лишь несколько верхних пикселей. Кто-то отправляет ему WM_WINDOWPOSCHANGING, что дает наблюдаемый эффект. Кроме того принудительная установка SWP_NOMOVE показала, что при сворачивании/разворачивании изменяется высота основного окна СБИС (то, которое со скроллбарами, класс BackgroundWindow), что есть ненормально.
(В ответ на comment #16) > Всё-же виноват не ребар. Его размеры не меняются, просто он опускается слишком > низко, и поэтому видно лишь несколько верхних пикселей. Кто-то отправляет ему > WM_WINDOWPOSCHANGING, что дает наблюдаемый эффект. Кроме того принудительная > установка SWP_NOMOVE показала, что при сворачивании/разворачивании изменяется > высота основного окна СБИС (то, которое со скроллбарами, класс > BackgroundWindow), что есть ненормально. Ищу автора WM_WINDOWPOSCHANGING.
Похоже, что сообщение всё-таки от MDI-окна. Дальше прогресса пока нет.
(В ответ на comment #18) > Похоже, что сообщение всё-таки от MDI-окна. Дальше прогресса пока нет. Не совсем так. MDI-окно получает WM_SIZE от кого-то. Пытался отследить источник этого сообщения. Стек вызовов раскручивается только на 4 вызова вниз и ничего интересного не дает. Пробовал зацепиться за ребар при поиске источника изменения размера - результат тот же самый. Пока получается, что единственный способ выяснить источник проблемы - написать тестовую программу с MDI. Причем скорее всего эффективность такого подхода будет невысокой, т.к. логи и трассировка ничего особенного не дали. Всё же другого варианта не вижу. Начал делать тестовую программу.
Продолжаю заниматься тестовой программой и по ходу разбираться с MDI.
Удалось выяснить механизм изменения размеров MDI-клиента. Установка его размера осуществляется вызовом SetWindowPos() из muzzle.dll. Ширина определяется лишь однажды на этапе инициализации программы, а в дальнейшем это значение просто суммируется с приращением ширины главного окна СБИС и полученный результат отдается SetWindowPos(). Вертикальный размер всегда рассчитывается вновь, очевидно чтобы учесть высоты меню, ребара и статусбара. При сворачивании главного окна размеры этих контролов становятся отрицательными, что приводит к чрезмерной высоте MDI-клиента. В итоге получается, что под Windows при сворачивании/разворачивании не генерируется сигнал на изменение размеров MDI-окна в отличие от Wine.
(В ответ на comment #22) > Удалось выяснить механизм изменения размеров MDI-клиента. Установка его размера > осуществляется вызовом SetWindowPos() из muzzle.dll. > ... > В итоге получается, что под Windows при сворачивании/разворачивании не > генерируется сигнал на изменение размеров MDI-окна в отличие от Wine. Проводил поиск события ведущего к вызову SetWindowPos(). Предположительно это что-то в обработке WM_SYSCOMMAND, но что именно - нужно уточнять.
(В ответ на comment #23) > (В ответ на comment #22) > > Удалось выяснить механизм изменения размеров MDI-клиента. Установка его размера > > осуществляется вызовом SetWindowPos() из muzzle.dll. > > ... > > В итоге получается, что под Windows при сворачивании/разворачивании не > > генерируется сигнал на изменение размеров MDI-окна в отличие от Wine. > > Проводил поиск события ведущего к вызову SetWindowPos(). Предположительно это > что-то в обработке WM_SYSCOMMAND, но что именно - нужно уточнять. Продолжаю работу в этом направлении. Поиск затруднен из-за сабклассинга целевых окон.
(В ответ на comment #24) > Продолжаю работу в этом направлении. Поиск затруднен из-за сабклассинга целевых > окон. Разбираюсь дальше, пока сдвиги весьма условные.
Решил сконцентрироваться на изучении механизма изменения MDI клиента. Вот что получилось: 1. DefFrameProc() в нем не задействована. 2. Размер меняется при любых манипуляциях с главным окном СБИС кроме WM_SYSCOMMAND c SW_MINIMIZE. По пути обработки этого сообщения есть вызов ShowWindow(), возможно что-то внутри него. P.S. Если развернуть дочернее MDI (например "Налогоплательщики"), то кнопки закрытия и сворачивания в оконном меню не работают.
DefFrameProc(), MDIClientWndproc_common() передают WM_SYSCOMMAND в DefWindowProc(). Отключение в ней обработки этого сообщения совершенно не влияет на проявление проблемы.
Идей нет, решил еще раз посмотреть вывод по WINEDEBUG=+mdi,+message,+win. Некоторую пищу для размышлений дало наличие WM_CHILDACTIVATE. Пытался подправить тестовое приложение отталкиваясь от этого - без сдвигов.
Работаю над задачей
Нашел за что можно ухватиться (как мне кажется). В свернутом состоянии клиентские прямоугольники окон под Wine и Win32 совершенно различны. В вайне они намного меньше реальных значений, которые наблюдаются в windows. Для корневого окна СБИС ситуация даметральна - в windows нулевой прямоугольник, а в wine хоть и маленький но все же не пустой. Начал исследование изменения размеров окон в windows.
В вайне свернутые окна не могут иметь клиентские области больше чем CX_ICON x CY_ICON. Почему так еще неясно, но думаю можно выяснить действительно ли причина в этом с помощью хака, который будет сохранять размеры клиентских областей перед свертыванием и подсовывать их о запросу от GetClientRect() Работаю над хаком.
Анализировал логи в надежде найти место где ломается правильное позиционирование MDI-клиента. Первый раз некорректный размер ставится здесь: trace:win:GetWindowRect hwnd 0x100dc (-32000,-32016)-(-31968,-31986) trace:win:GetWindowRect hwnd 0x100d8 (-32000,-31972)-(-30947,-31443) trace:win:GetWindowRect hwnd 0x100d8 (-32000,-31972)-(-30947,-31443) trace:win:SetWindowPos hwnd 0x100d8, after 0x100d8, 0,28 (32x-44), flags 00000234 После попытки поймать это место под Win32 понял, что хожу кругами: > В итоге получается, что под Windows при сворачивании/разворачивании не > генерируется сигнал на изменение размеров MDI-окна в отличие от Wine.
Область поисков сужается. Размеры портятся во время обработки WM_WINDOWPOSCHANGED, которе отправляется при исполнении ShowWindow(hwnd, SC_MINIMIZE), где дескрипторотносится к главному окну СБИС. Есть разница во флагах, передаваемых в этом сообщении в Win32 и Wine. Коррекция не помогла. Пока помогло только отключение отправки этого сообщения.
(В ответ на comment #33) > Область поисков сужается. Размеры портятся во время обработки > WM_WINDOWPOSCHANGED, которе отправляется при исполнении ShowWindow(hwnd, > SC_MINIMIZE), где дескрипторотносится к главному окну СБИС. Есть разница во > флагах, передаваемых в этом сообщении в Win32 и Wine. Коррекция не помогла. > Пока помогло только отключение отправки этого сообщения. Потратил еще некоторое время на поиски в этом направлении. Пока без достойных внимания результатов.
Откладываем задачи, к которым не обращались более 100 дней.
Релиз 2.0 больше не актуален и не отгружается. Работа по поддержке СБиС++ больше не ведётся. Если потребуется продолжить работу, то перетест уже будет в актуальной сборке. Закрываю.
