Здравствуйте, __Ranger, Вы писали:
__R>Каким образом можно повторить поведение виндовых менюшек? Т. е при появлении моего окна фокус должен оставаться неизменным.
При создании окна включите WS_EX_NOACTIVATE в dwExStyle (extended window style).
Здравствуйте, Frostbitten, Вы писали:
F>При создании окна включите WS_EX_NOACTIVATE в dwExStyle (extended window style).
Да, есть такой стиль, но, к сожалению, работает лишь под 2000/XP. Какой-нибудь более универсальный метод?
Люди не должны править людьми. Это неестественно. Людьми должны править драконы
Здравствуйте, __Ranger, Вы писали:
__R>Каким образом можно повторить поведение виндовых менюшек? Т. е при появлении моего окна фокус должен оставаться неизменным.
Здравствуйте, c-smile, Вы писали:
CS>Это если ничего больше делать ненадо. Т.е. пассивные окна типа tooltip. CS>Если же нужно делать чего-то еще придется стучать в бубен.
Не катит, поскольку в окне могут быть элементы управления. Как бы в бубен постучать(можно и ногой)?
Люди не должны править людьми. Это неестественно. Людьми должны править драконы
__R>Не катит, поскольку в окне могут быть элементы управления. Как бы в бубен постучать(можно и ногой)?
Ну поскольку по умолчанию всплывающее меню является модальным окном (если не установлен стиль MNS_MODELESS), то у него есть собственный цикл обработки сообщений. Поэтому оно может получать сообщения (клава + мышь) даже не имея фокуса и оставаясь пасивным. Также при создании можно захватывать мышь и отслежвать её.
Далее, если верить исходникам виндовс, то меню при получении WM_ACTIVATE, делает активным предыдущее окно и отдаёт ему фокус обратно.
Здравствуйте, Lopcom, Вы писали:
__R>>Не катит, поскольку в окне могут быть элементы управления. Как бы в бубен постучать(можно и ногой)?
L>Ну поскольку по умолчанию всплывающее меню является модальным окном (если не установлен стиль MNS_MODELESS), то у него есть собственный цикл обработки сообщений. Поэтому оно может получать сообщения (клава + мышь) даже не имея фокуса и оставаясь пасивным. Также при создании можно захватывать мышь и отслежвать её.
L>Далее, если верить исходникам виндовс, то меню при получении WM_ACTIVATE, делает активным предыдущее окно и отдаёт ему фокус обратно
Тогда другая проблема — ко мне не будет приходить WM_KILLFOCUS, и не понятно как отслеживать переключение на другие окна.
Люди не должны править людьми. Это неестественно. Людьми должны править драконы
__R>Тогда другая проблема — ко мне не будет приходить WM_KILLFOCUS, и не понятно как отслеживать переключение на другие окна.
Что имеется ввиду под "переключение на другие окна"? Для меню всё просто, оно просто исчезает, если юзер щёлкает где-либо вне его, и отследить такое событие для меню и закрыть себя очень просто. А вот какую функциональность хотите вы, не совсем понятно. Опишите более подробно.
Здравствуйте, Lopcom, Вы писали:
__R>>Тогда другая проблема — ко мне не будет приходить WM_KILLFOCUS, и не понятно как отслеживать переключение на другие окна.
L>Что имеется ввиду под "переключение на другие окна"? Для меню всё просто, оно просто исчезает, если юзер щёлкает где-либо вне его, и отследить такое событие для меню и закрыть себя очень просто.
В обработке WM_KILLFOCUS и надо его скрывать, но оно ко мне не придет, т.к фокуса у моего окна нет. Возможно, есть другой способ определить переключения на другие окна?
Люди не должны править людьми. Это неестественно. Людьми должны править драконы
L>>Что имеется ввиду под "переключение на другие окна"? Для меню всё просто, оно просто исчезает, если юзер щёлкает где-либо вне его, и отследить такое событие для меню и закрыть себя очень просто.
__R>В обработке WM_KILLFOCUS и надо его скрывать, но оно ко мне не придет, т.к фокуса у моего окна нет. Возможно, есть другой способ определить переключения на другие окна?
Я лично такие варианты обрабатываю:
1. Тыкнули мышкой в клиентскую область окна твоего приложения (WM_LBUTTONDOWN и так далее)
2. Тыкнули мышкой в неклиентскую область окна твоего приложения (WM_NCLBUTTONDOWN и так далее)
3. Переключились в другое приложение (WM_ACTIVATEAPP)
4. Нажали клавишу (которую я не обрабатываю специальным образом)
Вроде хватает, чтобы более-менее нормально работало окошко автокомплита
A>>3. Переключились в другое приложение (WM_ACTIVATEAPP)
__R>WM_ACTIVATE ко мне тоже не приходит
Ну например такой вариант:
1) Захватываем окно (SetCapture)
2) Отслеживаем WM_LBUTTONDOWN
Если координаты курсора GET_X_LPARAM(lParam) и GET_Y_LPARAM(lParam)
лежат за пределами окна, то закрываем окно.
Таким образом, если пользователь щёлкнет где-либо за пределами окна,
это будет означать активность пользователя за пределами окна, что
должно приводить к его закрытию, как в случае меню.
Здравствуйте, Lopcom, Вы писали:
L>Ну например такой вариант: L>1) Захватываем окно (SetCapture)
Это было бы замечательно, но
Only the foreground window can capture the mouse. When a background window attempts to do so, the window receives messages only for mouse events that occur when the cursor hot spot is within the visible portion of the window.
У меня как раз foreground.
Судя по всему, мне светят хуки...
Люди не должны править людьми. Это неестественно. Людьми должны править драконы
Здравствуйте, __Ranger, Вы писали:
__R>Судя по всему, мне светят хуки...
Я тоже так раньше думал Но в действительности все оказалось проще
Советую посмотреть:
1) MSDN раздел Keyboard Input
2) WM_MOUSEACTIVATE
3) MSDN раздел Messages and Message Queues, в частности функции PeekMessage, GetMessage, TranslateMessage, DispatchMessage;
4) пример в Platform SDK — ищи fakemenu.c
5) плюс то что я тебе ранее говорил
Здравствуйте, asheff, Вы писали:
A>Здравствуйте, __Ranger, Вы писали:
__R>>Судя по всему, мне светят хуки...
A>Я тоже так раньше думал Но в действительности все оказалось проще
A>Советую посмотреть: A>1) MSDN раздел Keyboard Input A>2) WM_MOUSEACTIVATE A>3) MSDN раздел Messages and Message Queues, в частности функции PeekMessage, GetMessage, TranslateMessage, DispatchMessage; A>4) пример в Platform SDK — ищи fakemenu.c A>5) плюс то что я тебе ранее говорил
A>Удачи!
Видимо предлагается такой вариант:
1. SetCapture на активное окно
2. Затем ставится отдельная вертушка ссобщений while (GetMessage(&msg, NULL, 0, 0)), к-я выбирает сообщения из активного окна, поскольку моё окно отображается SW_SHOWNOACTIVATE и сообщения туда не приходят
3. Фильтруются сообщения
К сожалению, SetCapture вешается только на окна того же процесса, а у меня активное окно может быть любого процесса. Есть, правда, ещё AttachThreadInput, но он, наколько я помню, работает только с клавиатурой
Люди не должны править людьми. Это неестественно. Людьми должны править драконы
Здравствуйте, __Ranger, Вы писали:
__R>1. SetCapture на активное окно __R>2. Затем ставится отдельная вертушка ссобщений while (GetMessage(&msg, NULL, 0, 0)), к-я выбирает сообщения из активного окна, поскольку моё окно отображается SW_SHOWNOACTIVATE и сообщения туда не приходят __R>3. Фильтруются сообщения
__R>К сожалению, SetCapture вешается только на окна того же процесса, а у меня активное окно может быть любого процесса. Есть, правда, ещё AttachThreadInput, но он, наколько я помню, работает только с клавиатурой
Честно говоря, я не понял — зачем тебе нужно применять SetCapture, и что означает "у меня активное окно может быть любого процесса".
Здравствуйте, asheff, Вы писали:
A>Честно говоря, я не понял — зачем тебе нужно применять SetCapture, и что означает "у меня активное окно может быть любого процесса".
Знаеш, я тебе давал рекомендации как сделать окошко типа autocomplete code в MSVS (или например типа popup menu). Там действительно надо, чтобы фокус оставался на прежнем месте.
А в твоем случае — ты переключаешся на другое приложение (твой ALight). Оно становится foreground, а бывшее активное окно — backgroung (со всеми последствиями — типа потери фокуса).
Ты хочеш изменить такое поведение? Чтобы отображалось твое меню, и при этом текущее активное приложение так и оставалось активным? Начнем с того, что примеров такой функциональности я не наблюдал. И не совсем понятно, зачем это надо.
Мне понятно, когда popup menu не забирает на себя фокус. Например, чтобы оставить фокус ввода на редакторе, и при этом юзер может выбрать в popup menu какое-то действие — типа вставить текст из clipboard. Если бы менюшка забирала фокус — то хрен бы было понятно, куда это действие применять.
А в твоем случае, зачем оставлять фокус?
... << RSDN@Home 1.1.0 stable >>
Re[16]: Меню+фокус
От:
Аноним
Дата:
16.04.04 16:24
Оценка:
Здравствуйте, asheff, Вы писали:
A>А в твоем случае, зачем оставлять фокус?
Дело в том, что в диалогах при нажатии на кнопку на тулбаре и появлении меню снимается фокус с диалога, и меню при этом выгдядит чужеродно. Хотел избавится от этого эффекта, но, видимо, не судьба В любом случае спасибо
