I use the SetWindowPos api to make my window topmost with the HWND_TOPMOST param.
It works fine, but still tooltips are on top of it.
How to make my window on top of all. Is there an api that I'm missing?
Edit: I fixed it with a timer checking the foreground window and then setting mine to topmost.
There is no way to do that, as noted in the Old New Thing blog. TopMost is TopMost. If two windows are competing one must loose. There is no secret MoreTopMost constant.
Related
It is possible to use the SetWindowPos API on Windows to keep a windows always on top of other windows, and there are many questions on StackOverflow dealing with this.
It is possible to keep only part of a Window always visible? I.e. specify a clipping region inside an existing window, and keep only that part visible?
A use case would be the following (on Windows):
User clicks on icon to run app.
User highlights a portion of the screen to focus on (similar to the Snipping Tool on Windows 7)
The highlighted part of the screen remains always visible, even when other windows/programs are moved over the selected region.
I know the issues that would spring up with having other applications that are also set to being topmost. Just curious if this is even possible?
Even if you change part of your window to be transparent to what's below (with a clipping region) it's still going to take all the mouse clicks, etc. that occur over the transparent part.
Your best bet is to create a new smaller window and make it top-most while hiding the main one.
I want my frame to be always on top, but I want it to be really on top. I want no other windows to hide it, even if they are also "always on top". I'm using wx.STAY_ON_TOP and wx.FRAME_FLOAT_ON_PARENT, but still there are windows that appear on top of mine. Also, the taskbar appears on top of my frame, while I'd like it to be behind my frame.
I've tried a lot of things that didn't work, detailed here.
Any idea how to make my frame really on top?
Because their is no standard method in doing so, as it is most often an undesired effect, you can possibly achieve this by frequently setting the topmost flag again to "overrule" any other applications going for the topmost position. You could do this using a timer which sets the value every x ms, or you can try and only set the ontop flag again when the window has lost focus. The events to set the ontop flag are:
EVT_SET_FOCUS
EVT_KILL_FOCUS
Try using this:
wx.Frame.SetFocus()
My application is a Windows Forms one.
I tried using the windows wallpaper, but this depends on the "Fill", "Stretch", "Fit" or "Tile" settings.
I just need the image as it is on the desktop, but including the part "under" the taskbar, because this part is visible in case of transparent taskbar.
Why I need this?
Because I have a tray application which slides from under the taskbar when opening. And I need to set a mask there, so it can't be seen sliding, until it reaches the top of the taskbar. Again, this is only a problem when the taskbar is transparent.
I am not sure if I understood your question correctly. But to me, it seems that you need the image that has created wallpaper. If it seems easier, take a look at registry entries at following location:
HKEY_CURRENT_USER\Control Panel\Desktop
This will give you the path, size, tile/no tile etc. information for the wallpaper.
There is a Win32 function called PaintDesktop you could try but unless I'm misunderstanding things you should be able to just adjust the height of your window so it is never really behind the taskbar...
Why I need this? Because I have a tray application which slides from under the taskbar when opening. And I need to set a mask there, so it can't be seen sliding, until it reaches the top of the taskbar. Again, this is only a problem when the taskbar is transparent.
The problem here is that you're starting the slide up from the bottom of the entire screen, rather than starting from the bottom of the screen's working area (i.e., the top of the taskbar). That's why you're seeing the pop-up window slide up behind a transparent taskbar.
Luckily, the solution is much simpler than obtaining the desktop background and/or doing any type of masking. It's also much faster, and it's always good that your eye candy isn't unnecessarily taxing the user's computer.
All you need to do is determine the coordinates of the screen's working area, which is defined by Windows as the area that can be used by applications, not including the taskbar and other side bars. You can obtain this information easily in WinForms by querying the Screen.PrimaryScreen.WorkingArea property. This will return a Rectangle that corresponds to the primary screen's working area. Since you know that the taskbar is always displayed on the primary screen, this is exactly what you want.
Once you have the coordinates of the primary screen's working area, start your pop-up window's slide from the bottom of that.*
This is a good lesson of why you should always include an explanation of why you want to accomplish something. There's often an even better way that you haven't thought of.
*Of course, I'm ignoring the fact that a user might not have their taskbar positioned at the bottom of the screen. You can put it on either side or even on top. It sounds to me like you haven't considered this in your question, either. If this is an app that you're writing only for yourself or for a controlled environment where you can be sure that no one has their taskbar in non-default positions, that might be OK. But if you're writing software to distribute to a wider audience, you will need to take this into account. The rcWork coordinates will be correct, regardless of where the taskbar is positioned, of course, but you will need to know whether to start the pop-up window's slide from the bottom, the left side, the right side, or the top.
So yes, I find myself in the dubious position of implementing a SwitchToThisWindow call to force my window to the front. I agree, its not ideal, but its not always possible to argue against product "features" that others deem necessary.
Now, I consider SwitchToThisWindow to be a win over the AttachThreadInput hack to do a forced window switch as its less likely to deadlock, and should SwitchToThisWindow be removed, or cease to function I won't complain.
However, SwitchToThisWindow has the unfortunate side effect of pushing the current foreground window to the bottom of the z-order in addition to bringing the target window to the top when FALSE is passed for the fAltTab parameter, and not doing anything if TRUE is passed.
How can I avoid this 'push current active to z-bottom' behavior without resorting to AttachThreadInput?
Alternatively, MS can just remove AttachThreadInput as a viable workaround and I can just tell my manager that the impossible, is in fact, actually, impossible.
I don't know if this helps, but the only way i found out to bring my window to top reliably is to make the following 2 calls:
ShowWindow(myhwnd, SW_MINIMIZE);
ShowWindow(myhwnd, SW_RESTORE);
Obviously these calls only should be made, when your window currently is not the topmost one in order to avoid flickering. But this also should not have the side effect of bringing the current front window to the bottom of the z order.
When passing fAltTab=FALSE you are actually emulating Alt+Esc. So you could reverse this z-order change with SetWindowPos and its hWndInsertAfter after the SwitchToThisWindow call, but then you are back in ugly hacky-land IMHO.
The question is, do you really need keyboard focus?
Let me suggest another alternative:
If your window is minimized, restore it
Set your window to be topmost, when your window is activated remove the style again.
Call SetForegroundWindow to flash the taskbar button (Or FlashWindowEx)
This should avoid the scenario where a user is typing and ends up performing some action in your UI without even looking at the screen.
Edit:
HWND hwndFgnd=GetForegroundWindow();
SetWindowPos(hwnd,hwndFgnd,0,0,0,0,SWP_NOSIZE|SWP_NOMOVE|SWP_NOACTIVATE);
SetWindowPos(hwndFgnd,hwnd,0,0,0,0,SWP_NOSIZE|SWP_NOMOVE);
..will probably work if you don't want to set the topmost bit at any point (Even if your window is at the top of the z-order, you still can't legally get the focus with SetForegroundWindow)
This is a bad problem I faced too. See my solution here. It works both for Show() and ShowDialog().
We have a fairly complex GUI, so when certain windows are resized their Redraw() is set to false till the operation is completed. The problem with this is that if the OS "Show window content while dragging" setting is checked, when decreasing the window's size the windows behind it are not repainted. This means I have to force the repaint myself so the remains of the resized window are deleted. I have no problem getting the dimensions of the region that was uncovered. What I'm looking for is best way to cause all windows within that region to repaint their part.
Not being much of a GUI programmer, I can traverse the uncovered region and list the windows in it. Then, I can ask each one of them to repaint its part. But I'm quite certain there has to be a better way to do this...
It is worth mentioning the app is written in PowerBuilder. This means I can call whatever Win32 function I'd like, but have limited control over the GUI behavior and the message handling. If there's a better way to prevent the window's content resize from being visible, or there's a way to make a non-redrawn window clean after itself, I'd love to hear it (just have the limitations above in mind).
I'm curious what version of PowerBuilder you are working in? I do resizing all the time and never run into issues like you are describing.
Maybe you can lay out some more detail on why you need to set your redraws to false within the PowerBuilder environment.
Hope I can help.