Bug 8242

Summary: СБиС++ ЭО: проблема со строкой состояния после сворачивания окна
Product: WINE@Etersoft Reporter: Александр Морозов <amorozov>
Component: Окна / фокус / перерисовкаAssignee: Сергей Гуральник <serhio>
Status: CLOSED INVALID QA Contact: Svetlana Zhukova <svzhu>
Severity: minor    
Priority: P4 CC: dtr, olezha, serhio
Version: 2.0   
Target Milestone: ---   
Hardware: PC   
OS: Linux   
Whiteboard:
Заявки RT: Связано с:
Дата напоминания:
Bug Depends on:    
Bug Blocks: 502    
Attachments: Окно до сворачивания
Окно после сворачивания

Description Александр Морозов 2012-02-27 18:01:42 MSK
Если свернуть и развернуть окно СБиС++ ЭО, то куда-то пропадает строка состояния.

СБиС++ ЭО 2.4.43
buh/sbis/2.4.43 на eterhack
WINE@Etersoft SQL 2.0.0-eter2.17/8
Comment 1 Александр Морозов 2012-02-27 18:04:25 MSK
Created attachment 2443 [details]
Окно до сворачивания
Comment 2 Александр Морозов 2012-02-27 18:05:11 MSK
Created attachment 2444 [details]
Окно после сворачивания
Comment 3 Сергей Гуральник 2012-08-17 16:57:32 MSK
При запуске с "comctl32=n" проблема частично решается. Ребар не исчезает, но остальное содержимое окна СБИС рисуется так, будто ребара нет (уходит слишком низко). Начал исследование.
Comment 4 Сергей Гуральник 2012-08-21 11:59:16 MSK
(В ответ на comment #3)
> При запуске с "comctl32=n" проблема частично решается. Ребар не исчезает, но
> остальное содержимое окна СБИС рисуется так, будто ребара нет (уходит слишком
> низко). Начал исследование.

comctl32 здесь не причём. Такая ненормальная реакция наблюдается только при сворачивании.разворачивании. Растягивание окна ничего не портит.
Comment 5 Сергей Гуральник 2012-08-21 18:18:54 MSK
Проблема есть и при эмулировании рабочего стола. Вероятно она где-то в user32. Похоже, что статусбар и ребар сохраняют свои размеры, но закрываются окном-близнецом. Причем этот близнец имеет неправильные размеры, почему так - пока неясно.
Comment 6 Сергей Гуральник 2012-08-21 18:20:43 MSK
(В ответ на comment #5)
> ... и ребар сохраняют свои размеры, но закрываются окном-близнецом.

s/закрываются/перекрываются/g
Comment 7 Сергей Гуральник 2012-08-23 17:10:22 MSK
Пытаюсь понять логику изменения размеров проблемных контролов. Сейчас есть предположение, что проблема связана с MDI-Client-окном СБИС. (Это согласуется с тем, что нативная comctl32 не решает проблему).
Comment 8 Сергей Гуральник 2012-08-29 16:21:32 MSK
(В ответ на comment #7)
> Пытаюсь понять логику изменения размеров проблемных контролов. Сейчас есть
> предположение, что проблема связана с MDI-Client-окном СБИС. (Это согласуется с
> тем, что нативная comctl32 не решает проблему).

Начал поиск в єтом направлении, пока ситуация не проясняется.
Comment 9 Сергей Гуральник 2012-09-12 17:19:21 MSK
(В ответ на comment #8)
> (В ответ на comment #7)
> > Пытаюсь понять логику изменения размеров проблемных контролов. Сейчас есть
> > предположение, что проблема связана с MDI-Client-окном СБИС. (Это согласуется с
> > тем, что нативная comctl32 не решает проблему).
> 
> Начал поиск в єтом направлении, пока ситуация не проясняется.

Дополнительный поиск не дал результатов, скорее всего MDI здесь ни причем.
Comment 10 Данил Плешаков 2012-11-02 15:44:35 MSK
eter-2.0 bugs/8766

Аналогично реагируют все ребары в СБиСе. Есть предположение, что выставляется минимальный размер, заданный при инициализации ребара.
Comment 11 Сергей Гуральник 2012-11-02 18:44:00 MSK
(В ответ на comment #10)
> eter-2.0 bugs/8766
> 
> Аналогично реагируют все ребары в СБиСе. Есть предположение, что выставляется
> минимальный размер, заданный при инициализации ребара.

А с "comctl32=n" не пробовал? Как всё выглядит?
Comment 12 Сергей Гуральник 2012-11-07 15:44:03 MSK
Продолжаю поиски проблемы.
Comment 13 Сергей Гуральник 2012-11-12 17:14:34 MSK
(В ответ на comment #12)
> Продолжаю поиски проблемы.

По текущим результатам создается впечатление, что проблема как в user32 так и в comctl32. Причем что именно в юзере - неясно. (Лучше начать с неё сделав comctl32=n).
Comment 14 Сергей Гуральник 2012-11-19 16:23:09 MSK
Работаю над задачей.
Comment 15 Сергей Гуральник 2012-11-21 19:17:11 MSK
Анализирую последовательности оконных сообщений. Пока ничего интересного не нашел.
Comment 16 Сергей Гуральник 2012-11-27 16:50:14 MSK
Всё-же виноват не ребар. Его размеры не меняются, просто он опускается слишком низко, и поэтому видно лишь несколько верхних пикселей. Кто-то отправляет ему WM_WINDOWPOSCHANGING, что дает наблюдаемый эффект. Кроме того принудительная установка SWP_NOMOVE показала, что при сворачивании/разворачивании изменяется высота основного окна СБИС (то, которое со скроллбарами, класс BackgroundWindow), что есть ненормально.
Comment 17 Сергей Гуральник 2012-11-28 17:18:13 MSK
(В ответ на comment #16)
> Всё-же виноват не ребар. Его размеры не меняются, просто он опускается слишком
> низко, и поэтому видно лишь несколько верхних пикселей. Кто-то отправляет ему
> WM_WINDOWPOSCHANGING, что дает наблюдаемый эффект. Кроме того принудительная
> установка SWP_NOMOVE показала, что при сворачивании/разворачивании изменяется
> высота основного окна СБИС (то, которое со скроллбарами, класс
> BackgroundWindow), что есть ненормально.

Ищу автора WM_WINDOWPOSCHANGING.
Comment 18 Сергей Гуральник 2012-11-29 23:49:24 MSK
Похоже, что сообщение всё-таки от MDI-окна. Дальше прогресса пока нет.
Comment 19 Сергей Гуральник 2012-12-05 17:07:43 MSK
(В ответ на comment #18)
> Похоже, что сообщение всё-таки от MDI-окна. Дальше прогресса пока нет.

Не совсем так. MDI-окно получает WM_SIZE от кого-то. Пытался отследить источник этого сообщения. Стек вызовов раскручивается только на 4 вызова вниз и ничего интересного не дает. Пробовал зацепиться за ребар при поиске источника изменения размера - результат тот же самый. Пока получается, что единственный способ выяснить источник проблемы - написать тестовую программу с MDI. Причем скорее всего эффективность такого подхода будет невысокой, т.к. логи и трассировка ничего особенного не дали. Всё же другого варианта не вижу. Начал делать тестовую программу.
Comment 20 Сергей Гуральник 2012-12-06 18:20:29 MSK
Продолжаю заниматься тестовой программой и по ходу разбираться с MDI.
Comment 21 Сергей Гуральник 2012-12-07 19:56:18 MSK
Работаю над задачей.
Comment 22 Сергей Гуральник 2012-12-10 18:11:58 MSK
Удалось выяснить механизм изменения размеров MDI-клиента. Установка его размера осуществляется вызовом SetWindowPos() из muzzle.dll. Ширина определяется лишь однажды на этапе инициализации программы, а в дальнейшем это значение просто суммируется с приращением ширины главного окна СБИС и полученный результат отдается SetWindowPos(). Вертикальный размер всегда рассчитывается вновь, очевидно чтобы учесть высоты меню, ребара и статусбара. При сворачивании главного окна размеры этих контролов становятся отрицательными, что приводит к чрезмерной высоте MDI-клиента. 
В итоге получается, что под Windows при сворачивании/разворачивании не генерируется сигнал на изменение размеров MDI-окна в отличие от Wine.
Comment 23 Сергей Гуральник 2012-12-11 18:21:27 MSK
(В ответ на comment #22)
> Удалось выяснить механизм изменения размеров MDI-клиента. Установка его размера
> осуществляется вызовом SetWindowPos() из muzzle.dll. 
> ...
> В итоге получается, что под Windows при сворачивании/разворачивании не
> генерируется сигнал на изменение размеров MDI-окна в отличие от Wine.

Проводил поиск события ведущего к вызову SetWindowPos(). Предположительно это что-то в обработке WM_SYSCOMMAND, но что именно - нужно уточнять.
Comment 24 Сергей Гуральник 2012-12-12 18:45:15 MSK
(В ответ на comment #23)
> (В ответ на comment #22)
> > Удалось выяснить механизм изменения размеров MDI-клиента. Установка его размера
> > осуществляется вызовом SetWindowPos() из muzzle.dll. 
> > ...
> > В итоге получается, что под Windows при сворачивании/разворачивании не
> > генерируется сигнал на изменение размеров MDI-окна в отличие от Wine.
> 
> Проводил поиск события ведущего к вызову SetWindowPos(). Предположительно это
> что-то в обработке WM_SYSCOMMAND, но что именно - нужно уточнять.

Продолжаю работу в этом направлении. Поиск затруднен из-за сабклассинга целевых окон.
Comment 25 Сергей Гуральник 2012-12-19 18:29:29 MSK
(В ответ на comment #24)
> Продолжаю работу в этом направлении. Поиск затруднен из-за сабклассинга целевых
> окон.

Разбираюсь дальше, пока сдвиги весьма условные.
Comment 26 Сергей Гуральник 2012-12-20 20:32:52 MSK
Решил сконцентрироваться на изучении механизма изменения MDI клиента. 
Вот что получилось:

1. DefFrameProc() в нем не задействована.
2. Размер меняется при любых манипуляциях с главным окном СБИС кроме 
   WM_SYSCOMMAND c SW_MINIMIZE.

По пути обработки этого сообщения есть вызов ShowWindow(), возможно что-то внутри него.

P.S. Если развернуть дочернее MDI (например "Налогоплательщики"), то кнопки закрытия и сворачивания в оконном меню не работают.
Comment 27 Сергей Гуральник 2012-12-24 18:22:08 MSK
DefFrameProc(), MDIClientWndproc_common() передают WM_SYSCOMMAND в DefWindowProc(). Отключение в ней обработки этого сообщения совершенно не влияет на проявление проблемы.
Comment 28 Сергей Гуральник 2012-12-25 17:09:41 MSK
Идей нет, решил еще раз посмотреть вывод по WINEDEBUG=+mdi,+message,+win. Некоторую пищу для размышлений дало наличие WM_CHILDACTIVATE. Пытался подправить тестовое приложение отталкиваясь от этого - без сдвигов.
Comment 29 Сергей Гуральник 2013-01-09 17:03:16 MSK
Работаю над задачей
Comment 30 Сергей Гуральник 2013-01-14 19:16:17 MSK
Нашел за что можно ухватиться (как мне кажется). В свернутом состоянии клиентские прямоугольники окон под Wine и Win32 совершенно различны. В вайне они намного меньше реальных значений, которые наблюдаются в windows. Для корневого окна СБИС ситуация даметральна - в windows нулевой прямоугольник, а в wine хоть и маленький но все же не пустой. Начал исследование изменения размеров окон в windows.
Comment 31 Сергей Гуральник 2013-01-15 17:48:27 MSK
В вайне свернутые окна не могут иметь клиентские области больше чем CX_ICON x CY_ICON. Почему так еще неясно, но думаю можно выяснить действительно ли причина в этом с помощью хака, который будет сохранять размеры клиентских областей перед свертыванием и подсовывать их о запросу от GetClientRect() Работаю над хаком.
Comment 32 Сергей Гуральник 2013-01-16 19:21:39 MSK
Анализировал логи в надежде найти место где ломается правильное позиционирование 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.
Comment 33 Сергей Гуральник 2013-01-17 21:21:33 MSK
Область поисков сужается. Размеры портятся во время обработки WM_WINDOWPOSCHANGED, которе отправляется при исполнении ShowWindow(hwnd, SC_MINIMIZE), где дескрипторотносится к главному окну СБИС. Есть разница во флагах, передаваемых в этом сообщении в Win32 и Wine. Коррекция не помогла. Пока помогло только отключение отправки этого сообщения.
Comment 34 Сергей Гуральник 2013-01-24 15:55:22 MSK
(В ответ на comment #33)
> Область поисков сужается. Размеры портятся во время обработки
> WM_WINDOWPOSCHANGED, которе отправляется при исполнении ShowWindow(hwnd,
> SC_MINIMIZE), где дескрипторотносится к главному окну СБИС. Есть разница во
> флагах, передаваемых в этом сообщении в Win32 и Wine. Коррекция не помогла.
> Пока помогло только отключение отправки этого сообщения.

Потратил еще некоторое время на поиски в этом направлении. Пока без достойных внимания результатов.
Comment 36 Vitaly Lipatov 2014-09-11 18:47:18 MSK
Откладываем задачи, к которым не обращались более 100 дней.
Comment 37 Олег Шевченко 2024-03-20 23:49:07 MSK
Релиз 2.0 больше не актуален и не отгружается. Работа по поддержке СБиС++ больше не ведётся.
Если потребуется продолжить работу, то перетест уже будет в актуальной сборке. Закрываю.