[Interest] win: can't trap WM_ENTER/EXITMENULOOP?

[David M. Cotter]

> QMenu are just “custom drawn widgets” not native widgets. 
got it, that explains that.

>>> Instead look into QMenu::aboutToShow and QWidget::closeEvent
>> does that work for the ENTIRE menu bar browsing workflow?
>>  
>> ie: get a "start" message when the user clicks the first time in the menu bar, and the user can then browse through all available menus if they like, and when they're done, whether they click OFF the menu bar (choosing no menu item) or if they do happen to pick a menu item, then i get one "finished" event message?
>>  
>> cuz that's what i need.
> Not quite sure what you need, but you will get a signal before the menu is shown
it's not about one menu. it's about the menu BAR. ie: all menus in the menu bar.

i do NOT want an "about to show" for every menu the user browses to within the same "menu bar browsing" session. i want one "about to browse menu bar" event, and then one "finished browsing menu bar" event when the user either picks a menu item or clicks off the menu bar.

i know i can trap all mouse DOWN events, and see if the event is in the menu bar. sure. part 1 solved
but how do i know if the user clicks OFF the menu bar (not picking something)?

> You can also setup slots on the individual QActions that are added to the menu.
that's exactly what i do not want to do. this is not about individual menus, much less individual menu items (actions)
this is about the global "browse the menu bar" user action.

i guess my question has morphed into: how can I accomplish what i'm after here?

>> Your solution (if it worked) would only work on Windows
>> that's all i care about. no other platform necessary.
> But all of Qt, is based on multi-platform support
it's fine if you care about that, but this is a single platform problem i'm solving. it works fine on mac, and i do not have a linux build anyway. (before you ask, the problem i'm solving is not part of this discussion)

:)

-dave