In my useful hotkeys program, i have a global hotkey which sets your current foreground window to be Topmost/Not topmost by calling
SetWindowPos(hwnd, HWND_TOPMOST,0,0,0,0,SWP_NOMOVE|SWP_NOSIZE);
SetWindowPos(hwnd, HWND_NOTOPMOST,0,0,0,0,SWP_NOMOVE|SWP_NOSIZE);
at the moment i have to have two separate hotkeys, Win+Z to set window to TOPMOST anjd Win+X to set window to NOTOPMOST.
I can't find a function in MSDN which lets you check the windows z order.. i was hoping for something like GetWindowOrder, but there isn't. I also tried checking the windows ex flags like so:
dwExStyles & WS_EX_TOPMOST
but it seems that flag isn't never changed, it just tells the window to set itself topmost when its first created.
Is there a function to check this?
I think you can do this:
DWORD dwExStyle = ::GetWindowLong(m_hWnd, GWL_EXSTYLE);
if ((dwExStyle & WS_EX_TOPMOST) != 0)
{
// do stuff
}
Here's the MSDN link - http://msdn.microsoft.com/en-us/library/ms633584(VS.85).aspx
And here's the MSDN link to the extended styles - http://msdn.microsoft.com/en-us/library/ff700543(v=VS.85).aspx - topmost is currently listed as "TBD" :)
You are looking for GetWindow():
Retrieves a handle to a window that
has the specified relationship
(Z-Order or owner) to the specified
window.
Related
I'm not able to use GetAltTabInfo. Probably a stupid mistake but what's wrong with this?
HWND taskSwitcher = FindWindow(L"TaskSwitcherWnd", L"Task Switching");
ALTTABINFO altTabInfo = {};
altTabInfo.cbSize = sizeof(ALTTABINFO);
GetAltTabInfo(taskSwitcher, -1, &altTabInfo, NULL, 0);
I have verified that taskSwitcher is the task switching window after the call to FindWindow (whether it is visible or not). All fields of altTabInfo remain 0 after the call to GetAltTabInfo except cbSize which was set to 40 by the assignment to sizeof(ALTTABINFO). I'm trying this on a windows 7 machine.
Alternative methods to extract the number of windows?
Thanks
Edit: Ok, I just realized I may get some error info. The result value of the GetAltTabInfo call is indeed 0 and GetLastError gives me either 1400 (Invalid window handle) or 1168 (Element not found) if I specify NULL for the hwnd parameter (it was after all defined to be __in_opt). So I guess I'm passing the wrong window. What is the right one if not the one returned by FindWindow(L"TaskSwitcherWnd", L"Task Switching")? MSDN only tells me about the hwnd parameter that "This window must be the application-switching window".
You always have to check for errors when you use Win32 API functions. GetAltTabInfo returns BOOL, call GetLastError() when it returns FALSE:
BOOL ok = GetAltTabInfo(hWnd, -1, &altTabInfo, NULL, 0);
if (!ok) {
int err = GetLastError();
Log(err); // Or whatever you use
return false;
}
I'll think you'll see error 1400, "Invalid window handle". On my machine, none of the window handles enumerated by EnumWindows() are accepted. I'd draw the conclusion that this API is no longer usable when you've got Aero enabled. I can't find independent confirmation for this.
i don't know for GetAltTabInfo, but you may use EnumWindow() to search for top-level windows and count them. that should tell you how many windows there are in the Alt-Tab window...
For what it's worth, as mokubai knew at https://superuser.com/questions/72946/disable-or-delay-alt-tab-aero-peek-effect-in-windows-7 , you can actually get the old style alt tab window visible even with win 7 aero enabled (left alt + tap right alt + tab (..I'm not kidding!!)). With that window visible the hwnd parameter in the GetAltTabInfo is irrelevant and in these circumstances you will still be able to get the Alt tab info.
I use CBT Windows Hook to detect window creation/deletion/min-max/move-size events.
I works well, but I need to filter whose events coming from normal widgets. Practically I need to being notified by CBT hook only for those windows that the user consider windows.
The problem that I'm facing make me mad, since I continuosly get spurious events even if I filter window as follow:
BOOL FilterWindowHandle(HWND hwnd)
{
// Filtered window having WS_CHILDWINDOW style
if ((GetWindowLongPtr(hwnd, GWL_STYLE) & WS_CHILDWINDOW) != 0)
return (TRUE);
// Filtered window not having WS_CAPTION style
if ((GetWindowLongPtr(hwnd, GWL_STYLE) & WS_CAPTION) == 0)
return (TRUE);
// Not filtered
return (FALSE);
}
Those spurious events comes from shadow effects, menus and everything displayed on screen.
Is there a robust method to filter real windows from its children?
I avoid the test of WS_BORDER or similar, since some applications could create their main window without border... or am I wrong?
A good fit for "things the user considers windows" is the set of windows displayed in the Alt-Tab list (or on the Taskbar).
This OldNewThing article explains the rules (although the rules are not fixed or guaranteed to remain the same):
Which windows appear in the Alt+Tab list?
The general rule is:
For each visible window, walk up its
owner chain until you find the root
owner. Then walk back down the visible
last active popup chain until you find
a visible window. If you're back to
where you're started, then put the
window in the Alt+Tab list.
This can be overridden with explicit window styles:
A window with the WS_EX_TOOLWINDOW
extended style is treated as if it
weren't visible, even if it is. A
window with the WS_EX_APPWINDOW
extended style is treated as if it has
no owner, even if it does.
See the full OldNewThing post which those two quotes come from for more detail.
A useful criteria that I've used in the past is to test whether the window is a top-level window, i.e. its parent is NULL.
Context:
I use glfw under xmonad. Glfw apparently sets the window title after creating the window, thus not allowing xmonad to properly handle it. I want to modify the glfw source so that I can set the window title before creating the window.
Problem:
So I download glfw-2.6, and I look into lib/x11/x11_window.c ; the lines causing the trouble are:
// Create a window
_glfwWin.Win = XCreateWindow(
_glfwLibrary.Dpy,
RootWindow( _glfwLibrary.Dpy, _glfwWin.VI->screen ),
0, 0, // Upper left corner
_glfwWin.Width, _glfwWin.Height, // Width, height
0, // Borderwidth
_glfwWin.VI->depth, // Depth
InputOutput,
_glfwWin.VI->visual,
CWBorderPixel | CWColormap | CWEventMask,
&wa
);
Followed sometime later by:
_glfwPlatformSetWindowTitle( "GLFW Window" );
where
void _glfwPlatformSetWindowTitle( const char *title )
{
// Set window & icon title
XStoreName( _glfwLibrary.Dpy, _glfwWin.Win, title );
XSetIconName( _glfwLibrary.Dpy, _glfwWin.Win, title );
}
Now, if I tr yto move the glfwPlatformSetWindowTitle call before the CreateWindow call, I get a segfault -- as I should, since _glfwWin.win would not be defined.
I don't know how to solve this problem since to set the window title, I need _glfwWin.Win to be initialized, but to initialize it, I need to create the window.
Thus, I ask: in X11, what is the proper way to set the window title before creating the window?
Thanks!
This is not possible in X11, but also not necessary for stuff to work. There must be a bug somewhere causing the symptoms you're seeing. The window title is just a property on the window, and properties can't exist until there's a window for them to be on.
You say "not allowing xmonad to properly handle it" which implies it isn't coping with changes to the name; window managers absolutely must handle setting the title at any time, including changing the title long after a window is created.
What the spec says (http://www.x.org/docs/ICCCM/icccm.pdf) is:
"The window manager will examine the contents of these properties when the window makes the
transition from the Withdrawn state and will monitor some properties for changes while the window is in the Iconic or Normal state."
The "transition from the Withdrawn state" is the point where glfw calls XMapWindow(). At that point, the window will remain unmapped but the WM will receive a MapRequest. The WM would then read properties and such and then map the window. All window managers I've ever seen also handle later changes to the property because changing the window title is pretty normal. For example web browsers the page title on every url.
If xmonad doesn't handle changes maybe it at least waits for the map, so maybe you just need to set title before XMapWindow(). Really all setup should be done before MapWindow though only a few properties are required to be before it by the specs. The props that must be before it generally can't be changed without unmapping.
Incidentally, _glfwPlatformSetWindowTitle won't work for anything but Latin-1. The modern way to do it is to set _NET_WM_NAME and _NET_WM_ICON_NAME with XChangeProperty() (setting the old Latin-1 WM_NAME is fine too but only as a fallback).
I'd like to obtain the same values via code. However I'd like to obtain the top-most or root windows in the hierarchy
I seem to have got the Root Parent with
HWND rootWinHandle = GetAncestor(activatedWinHandle, GA_PARENT);
However I can't get the owner window correctly. Tried
HWND rootOwnerWinHandle = GetAncestor(activatedWinHandle, GA_ROOTOWNER);
For a particular modeless dialog, Spy++ returns the Main Exe window whereas the above line returns the input i.e. activatedWinHandle. Am I looking at the wrong api ?
I'd like to obtain this without MFC if possible... coz nothing else in my project requires it.
See the GW_OWNER flag for GetWindow.
The GetParent documentation states:
If the window is a child window, the return value is a handle to the parent window. If the window is a top-level window, the return value is a handle to the owner window.
Try GetParent(). I believe this will return the owner window of a window without the WS_CHILD style, and the parent window of a window with WS_CHILD.
Only bit of insight i can add it from Raymond Chen:
Remember that owner and parent are two
different things.
Modal dialogs disable their OWNERs.
All top-level windows have the desktop
as their PARENT.
From: What's so special about the desktop window?
Special demo (+src):
http://files.rsdn.ru/42164/parentowner.zip
screenshot: http://files.rsdn.ru/42164/parentowner.png
kero
In Windows, is it possible to set window A such that it is always on top of window B, yet allow other windows to work as normal and appear over the top of both, when active.
In other words, I want a parent-child relationship between two windows. Can this be done without making window A a child of window B, MDI-style? Window B isn't mine (Internet Explorer), and screws my dialog A's graphics up when I try to achieve this with SetParent.
I thought I'd cracked it with this idea from an MSDN forum post, but alas windows A is still always on top of everything, not just window B.
// Place window A on top
SetWindowPos(hWndWindow, HWND_TOPMOST, 0, 0, 0, 0, SWP_NOMOVE|SWP_NOSIZE);
// Place window B underneath it
SetWindowPos(hWndParent, HWND_NOTOPMOST, 0, 0, 0, 0, SWP_NOSIZE|SWP_NOMOVE);
Is it possible?
Wouldn't creating an ownership relationship do the trick?
SetWindowLong(hwndChild, GWL_HWNDPARENT, hwndOwner)
The windows can be in different processes and you can call this from any process. This will ensure that the child window is always above the owner window. This is different than SetParent which actually creates a Parent / Child relationship. Read through this article (its from 1993 but still mostly correct) to see the distinction between ownership and parenting.
When your window's Z-order (or size or position) is changing, it should receive a WM_WINDOWPOSCHANGING message. If you process that message, you have an opportunity to modify the final Z-order (or size or position) to which the window is moved.
To illustrate, in hWndA's window procedure:
case WM_WINDOWPOSCHANGING:
DefWindowProc(hWnd, msg, wParam, lParam);
WINDOWPOS *p = (WINDOWPOS*)lParam;
p->hwndInsertAfter = hWndB;
p->flags &= ~SWP_NOZORDER;
return 0;
should insert hWndA after hWndB in the Z-order any time hWndA's position changes.
Until Vista, one way to do it would have been to use SetWindowsHookEx, and hook the WH_CBT or WH_CALLWNDPROC hook, and then take appropriate action when you detect the Z order changing. However this doesn't work with Vista (as far as I can tell from googling).
The only other solution I can think of is to set up a timer to fire every few seconds, and then when you receive a WM_TIMER, you interrogate the system using GetNextWindow to find out which window is behind yours. If it's not IE, then call SetWindowPos to position your window above IE (I assume you have a HWND for the IE window you care about - remember there can be multiple IE windows).
This will cause problems if people try to bring your window to the front - it will flip back to being just above IE. In this case, in your code you could handle WM_ACTIVATE and try to change the Z-order of IE's window so it's below your window (call SetWindowPos to move IE's window so it's above the window that is currently below your window). This solution may be fraught with problems as Windows may try to prevent you messing with the windows of another process, for security reasons. On the other hand, the MSDN docs for SetWindowPos don't explicitly mention that you can't manipulate the windows of another process. There may be obscure limitations though.
Even with this timer hack, you're going to effectively have a busy-waiting loop in your app (with the frequent WM_TIMER messages) and this is generally a bad thing to do, especially for battery life of laptops etc. (because you prevent the CPU from entering a sleep state, and so on).
I'd say there's no good way of doing this, and anything you're likely to get working will be brittle and cause problems. I strongly recommend not trying to do it. Is it possible to make your program into some kind of plug-in or toolbar for IE instead?
NB Be particularly aware that SetWindowsHookEx imposes a performance penalty at a system-wide level if you go down this route.
Maurice's answer is the best out of what's here but is missing an important step. When you call show on your window that you want as the overlay, you need to call the show method that has the parameter. You'll need to define a class that implements the IWin32Window interface and just make a new instance of that. The only thing that interface cares about is the Handle so just set that to the handle of the IE window and it should work pretty well
If the parent-child relationship is made by yourself with the SetWindowPos() function, your desire can be implemented.
Can you access the Z-order of the windows?
I cannot recall the default z-order of windows, but I think it is 1. You might be able to set IE to a -1 and your app to 0.
Try this:
// Place window A on top of window B
SetWindowPos(hWndA, hWndB, 0, 0, 0, 0, SWP_NOMOVE|SWP_NOSIZE);
The second window handle parameter specifies the next window down in the Z order.
Note this doesn't actually change the window parent-child relationships - but you can simulate it.