Здравствуйте, Евгений Музыченко, Вы писали:

ЕМ>Еще один. Вы б, народ, хоть в SDK заглянули, что ли. И WM_MOUSEACTIVATE, и WM_CHILDACTIVATE определяются еще в 2.0, в то время как MDI начинается только с 3.0, хотя некие его признаки появляются и в 2.11.

ЕМ>И еще раз, если это "про стандартный MDI", то почему его получают дочерние окна в моем простейшем примере без MDI?

Ну, ок. Может и не только для mdi child приходят. Но это всего лишь уведомление, что top level хозяин стал активным.
Скорее всего, для MDI это надо было, чтобы перерисовывалась рамка текущего (не хочу тут использовать слово "активного") mdi child при смене активности mdi frame.

Если для контрола как-то важна активность окна-хозяина, то имеет смысл обрабатывать.
На память приходят только тултипы со стилем TTS_ALWAYSTIP.

ЕМ>А какая разница-то? Какие силы зла мешают child-окну быть активным, кроме соответствующего постулата?
А что мешает EnumWindows перебирать child окна.
Так сделали...

ЕМ>Если это изначально прибили гвоздями, то для чего потом добавили стиль WS_EX_NOACTIVATE?
Фактически этот стиль определяет, что возвращает DefWindowProc для WM_MOUSEACTIVATE — "user clikcs it".

ЕМ>Вот есть окно с WS_CHILD, в нем есть Edit. Первый постулат: "окна с WS_CHILD не могут быть активными". Второй постулат: при клике мышью в Edit неактивного окна фокус не ставится". Какие есть типовые (чтобы оправдать такое поведение) ситуации, в которых установка фокуса в Edit при клике в него была бы интуитивно нежелательной?

Я приводил пример с edit, где как раз надо забирать фокус и активность.
Собственно, WM_MOUSEACTIVATE приходит, когда кликают над неактивным top level окном или его детками, внуками и т.д.

Кстати, MS использует термин "активность" не только для top level окон.
Есть еще активность для страниц в property sheet: PSN_SETACTIVE, PSN_KILLACTIVE.

Но та самая активность, которая GetActiveWindow/SetActiveWindow, привязана к GUI потоку с очередью сообщений (cм. структуру GUITHREADINFO).

Здравствуйте, Евгений Музыченко, Вы писали:

ЕМ>Еще один. Вы б, народ, хоть в SDK заглянули, что ли. И WM_MOUSEACTIVATE, и WM_CHILDACTIVATE определяются еще в 2.0, в то время как MDI начинается только с 3.0, хотя некие его признаки появляются и в 2.11.

ЕМ>И еще раз, если это "про стандартный MDI", то почему его получают дочерние окна в моем простейшем примере без MDI?

Ну, ок. Может и не только для mdi child приходят. Но это всего лишь уведомление, что top level хозяин стал активным.
Скорее всего, для MDI это надо было, чтобы перерисовывалась рамка текущего (не хочу тут использовать слово "активного") mdi child при смене активности mdi frame.

Если для контрола как-то важна активность окна-хозяина, то имеет смысл обрабатывать.
На память приходят только тултипы со стилем TTS_ALWAYSTIP.

ЕМ>А какая разница-то? Какие силы зла мешают child-окну быть активным, кроме соответствующего постулата?
А что мешает EnumWindows перебирать child окна.
Так сделали...

ЕМ>Если это изначально прибили гвоздями, то для чего потом добавили стиль WS_EX_NOACTIVATE?
Фактически этот стиль определяет, что возвращает DefWindowProc для WM_MOUSEACTIVATE — когда "user clicks it".

ЕМ>Вот есть окно с WS_CHILD, в нем есть Edit. Первый постулат: "окна с WS_CHILD не могут быть активными". Второй постулат: при клике мышью в Edit неактивного окна фокус не ставится". Какие есть типовые (чтобы оправдать такое поведение) ситуации, в которых установка фокуса в Edit при клике в него была бы интуитивно нежелательной?

Я приводил пример с edit, где как раз надо забирать фокус и активность.
Собственно, WM_MOUSEACTIVATE приходит, когда кликают над неактивным top level окном или его детками, внуками и т.д.

Кстати, MS использует термин "активность" не только для top level окон.
Есть еще активность для страниц в property sheet: PSN_SETACTIVE, PSN_KILLACTIVE.

Но та самая активность, которая GetActiveWindow/SetActiveWindow, привязана к GUI потоку с очередью сообщений (cм. структуру GUITHREADINFO).