How to distinguish between context menu and top-level menubar?

[WildByDesign]

I am using _GUICtrlMenu_IsMenu to determine whether or not specific handles are a handle to a menu. It is working very well which is nice. But the problem is that it also brings in context menu handles as well.

If _GUICtrlMenu_IsMenu determines that a handle is a menu, is there anything that I can do to further determine if that menu handle is part of the top-level menubar or a context menu?

Thank you.

[argumentum]

1 hour ago, WildByDesign said:

But the problem is that it also brings in context menu handles as well.

 bad idea.  

Edited Tuesday at 02:18 AM by argumentum

[QueefWellington]

9 hours ago, WildByDesign said:

If _GUICtrlMenu_IsMenu determines that a handle is a menu, is there anything that I can do to further determine if that menu handle is part of the top-level menubar or a context menu?

Try using _WinAPI_GetClassName() on the menu handle and see if there's a difference.

[WildByDesign]

6 minutes ago, QueefWellington said:

Try using _WinAPI_GetClassName() on the menu handle and see if there's a difference.

Thanks for the suggestion. Unfortunately _WinAPI_GetClassName() returns blank for all menus.

[QueefWellington]

Does checking the style work?

_WinAPI_GetClassLongEx($h_Menu, $GCL_STYLE)

[WildByDesign]

I just tried _WinAPI_GetClassLongEx right now and unfortunately it returned 0 for all top level menus and the context menus as well. I was hoping it would have been slightly different to differentiate between them, but no luck.

In this case, they all have the same parent window as well so I can't determine by parent either.

[pixelsearch]

The example from the help file, topic _GUICtrlMenu_CreatePopup, displays a popup menu using  _GUICtrlMenu_TrackPopupMenu . This menu got its own handle.

While the popup menu is displayed, it is possible, using a Timer, to retrieve the top-level window associated to this menu. For example, I got this result returned in an Array :

0x002E07B4   #32768  <== this is the popup window class name & handle (different from the menu handle)
0x002906F2   SysShadow
0x00070650   AutoIt v3 GUI

So in your case, facing a menu handle, you could do same and if you don't retrieve any top-level window having a class name #32768 associated to your thread, then it could mean that you're facing a non-popup menu handle.

For what it's worth...

[WildByDesign]

12 minutes ago, pixelsearch said:

So in your case, facing a menu handle, you could do same and if you don't retrieve any top-level window having a class name #32768 associated to your thread, then it could mean that you're facing a non-popup menu handle.

Thanks for your suggestion. In this particular case, it wont likely be possible because I can't rely on someone clicking on any of the menus. I have to detect them all before the GUI is shown.

I do think that I have an idea that should work. I am getting the menu text with _GUICtrlMenu_GetItemText() and I realized that the context menus always return blank for that. I am not as familiar with popup menus, so I will have to check and confirm with those.

So far I am pretty sure that I can assume that if _GUICtrlMenu_GetItemText() returns a text string, that should be a top-level menubar item. If it returns blank, then it cannot be a top-level menubar item. But before I go all in on implementing it, I will have to test any other menus like popup menus to see if they return text.

[WildByDesign]

1 hour ago, WildByDesign said:

So far I am pretty sure that I can assume that if _GUICtrlMenu_GetItemText() returns a text string, that should be a top-level menubar item. If it returns blank, then it cannot be a top-level menubar item

This ended up working perfectly in all of my testing scenarios. I am now able to automatically detect top-level menubars in scripts, obtain menubar text, handles and CtrlID of those items (that last part was the hardest part).

Now with that, I can automatically convert those menubars to OWNERDRAW and color them appropriately for dark mode. All without the user having to modify their script, with the exception of adding the UDF file as an include of course.