Ist it possible, given a HMENU, to detect if it's a popup or a drop down menu?
I want to create a (deep, modified) copy of an existing menu, and depending on this property I need to use either CreatePopupMenu or CreateMenu, respectively.
As Raymond Chen says here (with my emphasis):
CreateMenu creates a horizontal menu bar, suitable for attaching to a
top-level window. This is the sort of menu that says "File, Edit", and
so on. CreatePopupMenu creates a vertical popup menu, suitable for
use as a submenu of another menu (either a horizontal menu bar or
another popup menu) or as the root of a context menu.
If you get the two confused, you can get strange menu behavior.
Windows on rare occasions detects that you confused the two and
converts as appropriate, but I wouldn't count on Windows successfully
reading your mind.
There is no way to take a menu and ask it whether it is horizontal or
vertical. You just have to know.
Not clear with hmenu:
1) If you talk about hmenu, corresponding to the existing window (class #32768), it is sufficient to verify (via GetGUIThreadInfo) GUITHREADINFO.flags: availability GUI_INMENUMODE without GUI_POPUPMENUMODE without GUI_SYSTEMMENUMODE means that this menu - drop down.
2) If you talk about hmenu, existing in memory, we must find the root parent of this hmenu (btw, for menu there may be more than one, in contrast to the root parent window).
Then call TrackPopupMenu for found root parent and on WM_ENTERIDLE get hwnd appropriate window (class #32768) and call GetClientRect: if Rect =0, then the root parent = menubar (which can be created via LoadMenu(Indirect) or via CreateMenu), which means that the original hmenu - drop down (which can be created not only via CreatePopupMenu, but also via CreateMenu).
As for link to R.Chen. In reality the system always remembers exactly how was created hmenu in memory. But this mechanism (like so much else concerning the menu) is undocumented and Raymond obviously did not consider it necessary to uncover it...
Related
I've been trying to obtain text from a panel that's part of a third-party application; I have the process ID. To do this, I've gone through the usual EnumProcessModulesEx / GetModuleBaseName / EnumWindows / EnumChildWindows steps. This code works when the panel is shown, but when it's hidden, the panel is no longer seen by my code or Spy++. I'd figured the panel must be destroyed and re-created as the user hides and shows the panel, but it turns out that the HWND of the panel is valid in both situations (GetWindow, GetTitle, etc. all return without errors, and with the same information, so the handle hasn't been re-used); the only difference is that its parent is different. When I trace the parent chain back to the root, the topmost parent's title is WindowsFormsParkingWindow, same process ID. I searched for WindowsFormsParkingWindow, and it seems to be a temporary place to "park" a HWND when you don't need it, so you won't have to re-create the window and its children. Does anyone know of an API for traversing the WindowsFormsParkingWindow hierarchy, or some other way of getting to this panel? Thanks for any advice.
WindowsFormsParkingWindow is a message-only window.
You can enumerate message-only windows by calling FindWindowEx with the special window handle HWND_MESSAGE.
Based on information from this blog:
Flashback: Windows Forms Parking Window
The Parking Window is just a generic parent window used for arbitrarily re-parenting child windows onto during parent window recreations. There is no API to query information from the Packing Window itself, such as the original parent window for any given parked child window. Only the original parent/control knows which child HWND(s) have been parked so they can be retrieved when needed.
The best you are likely to accomplish is to detect when the panel is visible, remember that HWND, and then just use that HWND when needed, even when the panel is not visible. Or at least enumerate the WindowsFormsParkingWindow to check if that HWWND is still a child of it, etc. But if the panel is losing its text while parked, then you are likely to be out of luck.
I know about the option for system menu, that is the alt+space one. And it's not pretty it involves looping all open windows through GetNextWindow. But I want to ask in more general way. That is having any menu handle, not necessarily to system menu (that is easy to find for any window) is it possible to get to its parent window ?
In the particular case when hmenu obtained on the fly from an existing menu-window (class #32768):
you can use GUITHREADINFO.hwndMenuOwner via GetGUIThreadInfo(GetWindowThreadProcessId).
"On the fly" means: via SendMessageTimeout(MN_GETHMENU) or via GetMenuBarInfo(OBJID_CLIENT), after WindowFromPoint.
No. Menus can be shared across windows, so there's no unique mapping from menus to windows.
I've got some code that grabs the TaskBar buttons and their text from the windows TaskBar using User32.SendMessage with the TB_GETBUTTON message to retrieve a TBBUTTON structure (Win32 API via C# P/Invokes). But I'm trying to figure out how to then, once I have the handle to the button, grab the associated context menu text. There is some status information on there for a specific application that I would like to retrieve. The button text gets me some of it, but I need to the context menu text to complete it.
Any ideas?
This is not completely clear... Context menus don't have text, as such - they have menu items, each one of which will have text. By "context menu text", do you mean the text of the menu items in the taskbar button's popup/context menu? For example, "Restore", "Minimize" etc in the screenshot below?
If so, I suspect you're going about this the wrong way:
This menu doesn't belong to the button, but is the system menu of the window represented by the taskbar button. If the button has a context menu, this is probably for a grouped collection of windows, not one specific window (or even windows for one process.)
Making judgements based on the context menu of a window sounds like a dodgy approach to me, especially based on text since that will change depending on where in the world your user is located. Applications can also change the contents of this menu so there's no guarantee it will contain something you expect to be there. It would be better to check the window style, if it's minimized, etc, to find out the information that also affects the contents of the menu.
I'm going to answer this based on what your needs seem to be from the question, not what you've directly asked, since (a) it's not possible as asked and (b) I think you're trying to do something else. (As a general guideline, in a question it's good to state why you're trying to do something - and even maybe ask about that, ie 'how do I achieve X' - in case there's a better method than the one you're using. Here, X is probably 'find out information about this window' not 'get the text of the context menu', because that's probably only one possible method to get to X.) Also I think extracting data from the internals of a third-party application like Explorer (the taskbar is an Explorer window) is fragile and prone to break in future versions of Windows.
The system menu or window information (whichever one) belongs to application windows. Unless taskbar buttons are grouped (and then it's the subitems) one taskbar button corresponds to one specific window in the system. So what you want to do is find these windows. You do this by:
Using the EnumWindows function
Then for each window that is passed to the callback, checking the extended window style using GetWindowLong with GWL_EXSTYLE to see if the WS_EX_APPWINDOW bit is set
In addition, sometimes other windows are shown: these heuristics should help.
Each one of these windows is a window that should appear on the taskbar, Alt-Tab dialog, etc.
You say you're getting the text of the taskbar button - this is probably the window caption of the window, and GetWindowText is the canonical (read: probably a lot more reliable) way to get the caption of a window belonging to another process.
If you really want the popup menu, then:
Use GetSystemMenu to retrieve the handle for the system menu for the window. Applications can customise this, so if your app is doing this (and that's why you want the popup menu) ensure you pass false to the bRevert parameter
You can then get the number of menu items using GetMenuItemCount and for each one call GetMenuItemInfo to get info about each menu item. Pass true to the fByPosition parameter to indicate you're accessing the menus by position (since you know the count, you're getting item 0, 1, 2... count-1).
This fills a MENUITEMINFO structure, which (I think, I haven't ever had to code this so I haven't tested) will tell you the text associated with an item via the dwTypeData field "if the MIIM_STRING flag is set in the fMask member".
If you really want information about the window status, you can get this information using methods like IsIconic to see if it's minimized, GetWindowLong again to get other information, etc. I'd suggest you ask another SO question about how to get whatever specific information about a window for details.
Hope that helps!
Is it possible to create a dialog ressource with a resource editor and then put this dialog (possibly multiple times) into another dialog?
Here's some background. I need to create a C++ program (Windows). The user needs to input a set of similar data on a dialog. Say, for simplicity's sake, an element of this data-set consist of an edit control and a scrollbar. Since this combination (edit + scrollbar) needs to be put onto the dialog for each element for the data-set, I thought I could create a simple dialog with just one edit control and one scrollbar, and then put this dialog mutliple times onto its "parent" dialog.
So, is this possible at all. Any pointers will be greatly appreciated.
Yes, you can do this.
In the dialog editor, set the "Control Parent" flag on the parent dialog. (This will ensure the tab key works to cycle through items in the child dialogs as if they were part of the parent dialog.)
Make sure the child dialog(s) have the "Child" flag set in the dialog editor. Visually, they'll look like dialogs without any border at all in the editor.
At runtime, create the child dialogs as children of the parent dialog using CreateDialog (or CreateDialogParam, etc.). When calling CreateDialog you specify the dialogproc for each window.
I often make the child dialog procs do little more than forward messages to the main window's dialog proc (calling it directly; not via SendMessage), but you have to be careful, obviously. You have to be especially careful if you are creating multiple copies of the same dialog in a single parent, since obviously the control IDs within that dialog will all be the same and you need to differentiate them (perhaps by the parent's hWnd).
You don't have to forward messages to the parent, though. I just do usually do that so that most of the dialog's logic is in one place instead of spread out.
EDIT: Corrected statements about creating the child dialogs, window classes etc. I was mixing up dialogs and normal windows, making things more complex than they are in this case. Sorry about that!
In Win32 programming, what is the difference between a window's parent and a window's owner? I thought I had it figured out, then I came across this code:
SetWindowLong(handle, GWL_HWNDPARENT, foo);
This actually sets the window's owner, not the parent - despite the GWL_HWNDPARENT being used. Are the terms parent/owner interchangeable, or is there actually a difference?
Ownership is a relationship between two top level windows while Parent is a relationship between a top level and a WS_CHILD, or a WS_CHILD and another WS_CHILD.
The parent of a button is the form it is on, while a message box is owned by the form that showed it.
Read this article from Microsoft Win32 Window Hierarchy and Styles to get a much clearer understanding of Ownership, Parenting, ZOrder, SetWindowLong, GetWindow and all the other nasty bits of the Win32 api for creating window relationships.
EDIT: Looks like Microsoft took down that content, here is another reasonable summary of Ownership / Parenting.
Owner is the Window* responsible for a control or dialog (for example, responsible for creating/destroying the window).
Parent is the next-senior window* to a control or dialog in the window chain, but isn't actually responsible for it (doesn't necessarily care about its lifecycle, etc). A window's parent can also be its owner.
*Window vs window: Window is an actual window displayed on the screen; window is any object with a HWND (includes buttons, panels, etc).
Chen's blog post is the one to read. The key point for me is that the WS_CHILD style must be used on the child window. You can attempt to create a child window and pass the parent handle in to CreateWindow( ), but if you don't have the WS_CHILD style set the two windows will have the owner relationship, not the parent/child relationship.
It's super easy: the code is wrong. End of story right here.
Yes, some windows may happen to react favorably to such a call - someone not knowing any better may have implemented support for it. Quoth documentation (and it's old documentation) - You must not call SetWindowLong with the GWL_HWNDPARENT index to change the parent of a child window. Instead, use the SetParent function.
So, all there's to it: you came upon buggy code, change it to SetParent or refactor to do something else, and keep going?