In my Win32 app, I had a modal dialog that displays settings that I had to add more settings to. In order to fit the new settings, I dropped a TabCtrl in the dialog and implemented two modeless dialogs. The UI is working switching between them but the modeless dialogs don't respond to the keyboard. In a regular app, IsDialogMessage (hWndCurModelessDialog) would be called. How would I do this for my Modal dialog containing a modeless dialog?
You dont. The modal dialog box function calls IsDialogMessage from its own message loop automatically.
The modeless dialogs are the 'pages' ? Make sure they are parented to the main dialog (rather than the tab control) and have the DS_CONTROL style. This style allows IsDialogMessage to recurse into a child dialogs controls when tabbing.
Related
I have an application created with LabVIEW and I need to show/hide the application icon on the Windows taskbar at run time.
I think that WINAPI can be used for this purpose and I tried to use the ShowWindow function (user32.dll)
ShowWindow(hWnd,SW_HIDE) -> hides the application window. The taskbar icon disappears for a second than re-appears.
ShowWindow(hWnd,SW_SHOWMINIMIZED) -> It simply minimizes the application window, so the taskbar icon remains
By default a "normal" visible un-owned window gets a taskbar button and the taskbar button is visible in every state except SW_HIDE.
MSDN also documents a couple of tricks you can use to override the button:
The Shell creates a button on the taskbar whenever an application creates a window that isn't owned. To ensure that the window button is placed on the taskbar, create an unowned window with the WS_EX_APPWINDOW extended style. To prevent the window button from being placed on the taskbar, create the unowned window with the WS_EX_TOOLWINDOW extended style. As an alternative, you can create a hidden window and make this hidden window the owner of your visible window.
... If you want to dynamically change a window's style to one that does not support visible taskbar buttons, you must hide the window first (by calling ShowWindow with SW_HIDE), change the window style, and then show the window.
Another alternative is to use the ITaskbarList interface, it gives you full control over your taskbar button.
Is it possible to display the taskbar button when WS_EX_TOOLWINDOW flag is used in CreateWindowEx?
The WS_EX_APPWINDOW style is required for an unowned top-level window to display itself on the Taskbar.
The Extended Window Styles documentation specifically states that a "tool window does not appear in the taskbar".
MSDN further documents this in more detail:
The Taskbar
The Shell places a button on the taskbar whenever an application creates an unowned window—that is, a window that does not have a parent and that has the appropriate extended style bits (see Managing Taskbar Buttons, below).
...
Managing Taskbar Buttons
The Shell creates a button on the taskbar whenever an application creates a window that isn't owned. To ensure that the window button is placed on the taskbar, create an unowned window with the WS_EX_APPWINDOW extended style. To prevent the window button from being placed on the taskbar, create the unowned window with the WS_EX_TOOLWINDOW extended style. As an alternative, you can create a hidden window and make this hidden window the owner of your visible window.
The Shell will remove a window's button from the taskbar only if the window's style supports visible taskbar buttons. If you want to dynamically change a window's style to one that does not support visible taskbar buttons, you must hide the window first (by calling ShowWindow with SW_HIDE), change the window style, and then show the window.
...
Modifying the Contents of the Taskbar
Version 4.71 and later of Shell32.dll adds the capability to modify the contents of the taskbar. From an application, you can now add, remove, and activate taskbar buttons. Activating the item does not activate the window; it shows the item as pressed on the taskbar.
The taskbar modification capabilities are implemented in a Component Object Model (COM) object (CLSID_TaskbarList ) that exposes the ITaskbarList interface (IID_ITaskbarList). You must call the ITaskbarList::HrInit method to initialize the object. You can then use the methods of the ITaskbarList interface to modify the contents of the taskbar.
So, you might be able to use ITaskbarList::AddTab() for your tool window:
Any type of window can be added to the taskbar, but it is recommended that the window at least have the WS_CAPTION style.
I have a standard modal MFC dialog and I'd like to capture mouse clicks outside that dialog.
Is there a simple way to do this or do I have to transform the modal dialog into a modeless dialog?
We have a set of modeless dialogs that are children of a modal dialog. Only one of the modeless dialogs appears at a time; the others are hidden. This is controlled by elements in the modal dialog. If you think of a Windows property sheet you'll have the idea.
It all works fine except for the Tab key and the Alt+char hotkeys. They don't do what they're supposed to do, i.e., navigate the controls in the active modeless dialog. They just beep.
In a normal scenario, i.e., a modeless dialog owned by the application window, this is handled by calling IsDialogMessage() in the application's message loop. We can't do that because it's not our message loop--Windows is running the message loop to service the modal dialog, and all we get are messages sent to the dialog proc.
We're trying to think of ways to handle this without having to resort to doing all of the navigation ourselves via WM_GETDLGCODE.
Any ideas? Straight C++ Win32 API, none of that newfangled stuff the kids are all using these days.
TIA
ADDITIONAL INFO: Further investigation reveals that Windows is applying the navigation keys to the host modal dialog, not to the child modeless dialogs. We need them to go to the modeless dialogs.
The answer, found by a colleague, turns out to be adding the DS_CONTROL style to the modeless dialogs.
Raymond Chen discusses DS_CONTROL here.
It's amazing that you can work with Windows every day for 20 years and still run across stuff that you've absolutely never heard of.
I am using the new Common Item Dialog API to show file open/save dialogs. How do i get these dialogs to be centered on the owner window ? In the old API, this could be done by handling WM_INITDIALOG in the Callback hook for GetOpenFileName, but the IFileDialog does not seem to provide any way to center the dialogs.