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.
Related
I have an application (executable) where it displays an update dialog upon launch in front of the parent window. The dialog, of course, maintains the focus and top of the Z order for the application.
The parent window is therefore unselectable and cannot be moved or dragged etc.
Is there a way to modify the position of windows without focus in an external application?
Sometimes in the Windows OS, a program is able to open a new window which disables it's underlying window. Closing the newly opened window of course re-enables the first window. I want to enable the underlying window without closing the newly opened window with Autohotkey.
I made a gif which shows the situation perfectly:
https://imgur.com/a/EWt8OrF
I thought I might be able to pull this off with window styles and window extended styles, so here's what I tried:
^!e::
MouseGetPos,,, WindowUnderMouse
WinSet, Style, -0x8000000, ahk_id WindowUnderMouse
return
But it didn't work. I also did a lot of googling on this, but I didn't know what would be the proper keywords so I didn't find anything. Any idea how to accomplish this?
Some keywords for google:
How to make a modal window modeless
How to enable a disabled window
How to make a palette window
How to make a modal window a palette window
How to enable parent window
Child window disabling parent window
https://autohotkey.com/board/topic/49376-making-a-gui-dialog-modal/
https://autohotkey.com/docs/commands/Gui.htm
I'm developing a Application Desktop Toolbar (next Toolbar). Toolbar receives ABN_FULLSCREENAPP notification when a fullscreen application window is opened or closed (e.g. through F11). A window is fullscreen when its client area occupies the entire screen. Toolbar should take themselves out of the topmost z-order so that they do not cover the fullscreen window. For this I use SetWindowPos() with flag HWND_BOTTOM/HWND_TOPMOST.
Problem: On Windows 10 when a fullscreen application window is opened (e.g. Explorer window through F11) Toolbar receives ABN_FULLSCREENAPP and send themselves to bottom z-order. Then, when Win + Tab is pressed, Task View appears. Task View occupies the entire working area of the screen - entire screen exclude the Taskbar area and the Toolbar area. But Toolbar remains under the full-screen window and Takbar appears on top, see image below. I want the Toolbar to also be on top of the full-screen window when TaskVew is open.
During the opening of Task View, Toolbar does not receive any messages. Apparently since Microsoft stopped development of the ADT API, there is no special message for the Toolbars.
Possible solutions:
1) Use the solution from similar question by performing the function in the timer between the opening and closing of the full-screen window;
2) Use LowLevelKeyboardProc() with SetWindowsHookEx().
Both solutions are not elegant. If you know other method of detecting the opening / closing TaskView please report. Undocumented methods are also useful.
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've been researching popup menus (see https://msdn.microsoft.com/en-us/library/windows/desktop/ms647626(v=vs.85).aspx) and a bit confused at what they are behind the scenes.
They act partially like windows, but look like controls. For instance, they pop up above other elements, steal focus, and can go outside their parent container which makes me think they are a type of window. But they pass back an HMENU handle instead of a window handle, and they have no title bar, nor handles, nor show up in the task bar.
If they are a type of control, how can they go outside their parent window?
If they are a type of window, can I use window-specific functions on them? or if they are a control in a new window, is there a way to get a win handle to that new window?
Can I get the location of the popup menu for another application?
Found the answer:
trying to get a handle to a context menu in c++
Looks like a menu is a type of window, that is a child of the desktop window. You can get its window handle with EnumChildWindows on the desktop WinHandle and look for the class name of #32768.
There's more about these reserved system windows here:
About Window Classes | System Classes
A popup menu is a menu, not a window.
A menu merely uses a window for display. A new window is created each time the menu is displayed, and is destroyed afterward. By contrast, the same HMENU can be used to display the menu many times.