Здравствуйте, Евгений Музыченко, Вы писали:
ЕМ>К чему это здесь? Эта статья содержит утверждение ("When you set the DS_CONTROL style on a dialog template (or set the WS_EX_CONTROLPARENT extended style on a regular window), a bunch of new rules kick in. First of all, the WS_CAPTION and WS_SYSMENU styles in your dialog template are ignored. Because you’re a child window now, not a top-level window, so you don’t get a caption bar or a system menu"), но не его объяснение. Что мешало оставить все, как есть? Кому не нужны заголовок и системное меню, те могли бы сами убрать соответствующие стили.
Но в исходном описании задачи дочерние диалоги независимы, они не образуют непрерывное поле контролов, по которым юзер может бегать табуляцией.
Более того, их можно передвигать за заголовок так, что визуально порядок расположения контролов также будет меняться.
Мне вот не понятно, чем это отличается от обычного MDI.
А стиль DS_CONTROL позволяет как раз включить дочерний диалог в экосистему диалога-родителя.
Т.е. хочешь супер-контрол — получаешь без рамок, заголовка и проч., что контролу не свойственно.
Например, кладем 4 дочерних диалога на родительский и IsDialogMessage будет правильно обходить по Tab контролы как дочерних диалогов, так и родительского.
С символьными мнемонмками такая же история.
Здравствуйте, qaz77, Вы писали:
Q>в исходном описании задачи дочерние диалоги независимы, они не образуют непрерывное поле контролов, по которым юзер может бегать табуляцией.
Да, этого мне от них и не нужно. Поэтому у меня и не возникало идеи использовать DS_CONTROL, который туда по логике не подходит.
Q>Более того, их можно передвигать за заголовок Q>чем это отличается от обычного MDI.
Только предельной простотой. От этих окон не нужно ничего, кроме возможности таскать их за заголовок, работать с их элементами управления, и выборочно закрывать. От них не требуется более сложного поведения реализованного в MDI ((приложение — примитивный демонстрационный пример) , поэтому я и хочу ограничиться минимальной двухуровневой схемой из главного окна и диалогов-потомков. С костылем на WM_MOUSEACTIVATE вроде работает, как надо — надеюсь, дальше не вылезет никаких косяков.
Здравствуйте, Евгений Музыченко, Вы писали:
ЕМ>Создаю простое главное окно (WS_OVERLAPPEDWINDOW, WS_CLIPCHILDREN). К нему через CreateDialog создаю потомки-диалоги с WS_CLIPSIBLINGS. Навскидку все выглядит правильно — любой из диалогов можно кликнуть, потаскать внутри окна, покликать на элементы, но очень странно идет обработка нажатий клавиш. Если обхожу элементы типа ComboBox или Edit через Tab, то обход работает, содержимое полей выделяется инверсным, но при нажатии символьных клавиш ни в главное окно, ни в диалог не идут сообщения — соответственно, туда ничего не вводится.
ЕМ>Если открыть/закрыть ComboBox — ввод начинает работать нормально, потом снова затыкается.
ЕМ>В цикле обработки сообщений IsDialogMessage вызывается, как положено.
ЕМ>Отчего может быть такая хрень?
