Bug 8242

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 больше не актуален и не отгружается. Работа по поддержке СБиС++ больше не ведётся.
Если потребуется продолжить работу, то перетест уже будет в актуальной сборке. Закрываю.