В связи с вот этим

Автор: Fortnum
Дата: 28.10.10

, где я пытаюсь WPF окно превратить в Application Desktop Toolbar, и оно у меня иногда съезжает сразу после превращения, прошу помочь понять, как приложение (или окно) узнает о том, что изменилась WorkArea? В начале я ее узнаю через SystemParameters, но как приложение узнает о том, что пользователь взял и, к примеру, увеличил размер панели задач?

Есть такое подозрение, что это Windows сам перемещает мое окно (что маловероятно). Либо, что более вероятно, WPF-фреймворк где-то отрабатывает так, что перемещает мое окно в дефолтную позицию.

Здравствуйте, Fortnum, Вы писали:

F>В связи с вот этим

Автор: Fortnum
Дата: 28.10.10

, где я пытаюсь WPF окно превратить в Application Desktop Toolbar, и оно у меня иногда съезжает сразу после превращения, прошу помочь понять, как приложение (или окно) узнает о том, что изменилась WorkArea? В начале я ее узнаю через SystemParameters, но как приложение узнает о том, что пользователь взял и, к примеру, увеличил размер панели задач?

F>Есть такое подозрение, что это Windows сам перемещает мое окно (что маловероятно). Либо, что более вероятно, WPF-фреймворк где-то отрабатывает так, что перемещает мое окно в дефолтную позицию.

Есть какое-то волшебное системное событие, рапортующее об изменении рабочей области. Видел в каком-то блоге, когда гуглил на тему borderless wpf window. Ссылку найти не смог.

Здравствуйте, Vladek, Вы писали:

V>Есть какое-то волшебное системное событие, рапортующее об изменении рабочей области. Видел в каком-то блоге, когда гуглил на тему borderless wpf window. Ссылку найти не смог.

Я пока что нарыл только SystemEvents класс. Но цель, вообще говоря иная — понять почему после ABM_NEW к моему окну приходит WM_MOVE со старыми координатами и размерами — с теми, которые я получил во время создания окна, но которые я уже изменил сразу после ABM_NEW/ABM_SETPOS.

Нашел в сети пока только одну тему, где обсуждалась бы эта проблема.