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!
Related
For some fun and self-education, I'm tinkering with writing my own X11 toolkit. Here's something that's stumping me.
I have a traditional combo box display element, a typical combo box with a dropdown popup list, like all popular toolkits have.
For the dropdown popup list, I'm creating a new window, a child of the root window, appropriately positioned below the main combo-box display element.
The dropdown popup list is a window in its own full right, that implements keyboard-based navigation, to select the individual entries in the dropdown list.
So, I'm using SetInputFocus to set the input focus to the popup after it opens.
What I find is that when I do that, the window manager then redraws the frame of the main window to indicate that it no longer has input focus. Which is technically true, but I don't see the same results with the more mainstream toolkits, where, in the comparable situation, the main window's frame shows that it still has input focus.
For the pop-up window, in addition to setting override-redirect, I'm also doing everything I can think of, to tell the window manager what's going on: setting the window group leader ID in the popup window's WM_HINTS, setting WM_TRANSIENT_FOR, and setting _NET_WM_WINDOW_TYPE to _NET_WM_WINDOW_TYPE_COMBO; none of that seems to work (I verified that the properties are approriately set, via xprop).
It seems like I have to keep the input focus in the combo box window, and forward keypress and keyrelease events to the display elements in the dropdown popup, which feels clunky. Am I overlooking some property that would tell the window manager that the popup's input focus is linked to the main window's (besides the ones that I've mentioned), that would keep the main window's frame drawn to show that it has input focus, when the input focus is actually in the popup?
Most X11 override-redirect exclusive popup windows (menus, combo boxes, ...) grab the keyboard and/or pointer with either passive or active grab.
See XGrabKey, XGrabKeyboard, XGrabButton, XGrabPointer in the X11 programming manual.
Or maybe don't, because the manual is totally unclear about what the heck these functions are and how they can be used. Search the interwebs for usage examples, probably in other widget libraries. Unfortunately I don't know of a simple informative example offhand.
It is not necessary to call XSetInputFocus at all because all keyboard and/or pointer events are reported to the grabbing clients.
I'm learning Win32 assembly. Have some question I search but not suitable result.
Anyone can explain for me What difference between control's window handle and controlID.
They have nothing in common. Every window has a handle, returned by CreateWindowEx(). Such a window can have a few extra properties attached, like a menu handle. The hMenu argument in CreateWindowEx(). If the window doesn't have a menu, a child window won't have one, then you can use that argument to pass an arbitrary other bit of data. It will be assigned to the GWLP_ID property (see GetWindowLongPtr). Also note the GWLP_USERDATA, an extra property that's entirely yours to use as you see fit.
Dialogs take advantage of this, a dialog template that you create in the resource editor gives you a way to number the child controls. With a helper function like GetDlgItem() to get the handle back for a control with a specific number. Which is pretty necessary for dialogs since it is Windows that create the child controls from the dialog template so you don't know the window handles for them yourself.
In my WinAPI program I use PropertySheet for a settings dialog box. I use property sheet with pages (tabs), i.e. I use PSH_PROPSHEETPAGE flag. But the software now have too many parameters for such a type of property sheet. So I want to use PropertySheet with treeview: the treeview on the left and the page with paramerets for the currently selected item in the treeview - on the right.
How can I do this? Can my current property sheet be modified for this and how?
(using only WinAPI, no MFC)
Standard property sheet is no longer good enough for you, so you basically have two choices here. You can either design a window (modal or modeless, dialog based or not) to host all your controls in a single view, with tree view, possibly tab control as well, and showing/hiding elements to follow tree view selection. And you will move all your controls into this window.
Or instead, you can create a similar window which hosts property pages. On tree selection change you will switch property pages as if they are selected by tabs in standard property sheet. The point is that you can use your existing pages intact making this new settings windows imitating behavior of standard property sheet. This is perhaps a more complicated thing to do, but should be flexible enough to do once and accept various pages, and you don't also need to touch your existing pages code leaving it good for both standard and this custom sheet with a tree.
Both ways assume you need to do quite some work since you are giving up using a standard piece of code - the property sheet window.
I am studying GUI programming an am doing fine for very simple GUI scripts, but since the opportunities to prototype a bit larger, more complete "real world" programs, I'm having some doubts.
Specifically, I don't know how should I handle navigation between screens. For example:
I create a window
I create the window's content (a panel widget with lots of widgets)
One of the widgets, when clicked, "takes to another screen"
This "other screen" is supposedly something that replaces the current window content. But what should the program actually do?
- Destroy the panel widget?
- Hide/remove the panel widget, but let it "live" in memory, offscreen?
Destroying the whole window and creatin another one is most probably NOT the way to do it.
Some form of navigation (backtrack) is something I plan to achieve.
The core of the question is: how is it USUALLY done, on most programs - what is the "usual", or "current" or "obvious" way to do it?
Thanks for reading, and sorry if the question is confuse and/or vague.
(note: I use PyGTK, but I'd like to think que question is toolkit-agnostic)
The first window is the parent window and the window on a click or navigation can be your child window.. you can have a grand child window, grand grand child window, etc.
You need not delete the parent window. The child windows can be drawn on top of it.
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!