If I have a Winforms control, is it possible to tell if there are windows (from any application) above it? Basically, I need to know what parts of my control are actually visible on screen.
If you're happy to P/Invoke, the EnumWindows function enumerates all top-level windows on the screen giving a HWND; from that you can get the non-client rectangle (GetWindowRect) to compare against your form bounds.
This won't account for windows with non-rectangular opaque areas (fancy skins for media players and the like), so you may get false positives for such a window occluding your control.
In the Win32 API, you can use WindowFromPoint to determine the topmost window at any given point. This won't tell you if your whole control is visible, but if you test all 4 corners it gives you pretty good odds.
Why do you want this information? Typically when people ask this question it's because they want to ensure that their UI is in the foreground if it's not. And that usually is what happens just before they try to steal the focus away from the application which does have the foreground.
And foreground stealing is very, very, very bad. People get REALLY upset when applications steal focus.
Having said that, either of the two techniques above would work - I think I'd prefer the EnumWindows/GetWindowRect/IntersectRect technique in Steve Gilham's answer.
Related
I'm writing a HUD style application (just text, zero user interaction) and I want my text / water marks to always be visible regardless of other apps on the system.
I made myself a WPF popup and topmost but if other applications come along that want to be topmost as well they seem to supersede mine.
Is there win32 support to override this and effectively watermark system / appplication wide?
Nope. From Raymond Chen's blog: What if two programs tried to do this?
"How do I create a window that is never covered by any other windows,
not even other topmost windows?"
Imagine if this were possible and imagine if two programs did this.
Program A creates a window that is "super-topmost" and so does Program B.
Now the user drags the two windows so that they overlap. What happens?
You've created yourself a logical impossibility. One of those two windows
must be above the other, contradicting the imaginary "super-topmost" feature.
Now Im customizing title bar of my application. My aim is to add one extra button on title bar. Im my previous question people have adviced me the way I can customize non client area. Thats works perfectly except one small thing - glowing! I can draw glowing in nonclient area but I cannot make it spreads out of the window. I also cant find any resource about this subj.
I looked into this sample and made my own test app for investigating non client drawing facilities. Screen shot of my app's window:
So you can see that system button glows out of the windows when my is clipped by borderframe.
For example, Skype's window have four custom buttons in title bar and they can "glow" out of the window frame:
Can anybody advise me to find out the way to draw button's glowing out of the window?
Thanks in advance!
[EDIT]
Thank you everybody for answers!
Skype cheats it, and has a little sliver along the top of their window; where they can draw it.
You can see it with Process Explorer to SpyXX:
See also
MSDN: Custom Window Frame Using DWM
I don't think it's possible to draw beyond your NC area, and I kind of doubt they are drawing the whole UI to exactly match DWM Aero effects.
Given how this looks, I wonder if they did some tricks with either the help or restore button of a CustomBorderForm, which would then get the DWM blur highlight effect "for free".
Here's the most relevant article I could find to this: http://geekswithblogs.net/kobush/articles/CustomBorderForms3.aspx
Followup - I think this custom chrome thread has more pointers to the same techniques (although different goal): Custom titlebars/chrome in a WinForms app
AFAIK, this is not possible, because the area outside your window's border simply does not belong to you.
The Skype screenshot is from a custom-drawn frame that most likely extends a bit beyond the visible borders, not from an Aero Glass frame. You can tell the difference if you look carefully.
OK, anyone can explain how Jing take screen shots with that overlay form? It appears that it take a full screen shot and records all visible window handles and let you select within the form a specific hwnd. could be true? if is, what are the big steps to achieve this? could be a simple picturebox or without a custom control i don't have a chance to freeze the screen while taking a screen shot?
Thank you!
I'm not familiar enough with Jing to know exactly what it uses. But there are two basic techniques. One is as you mention, capture the screen and display it in a topmost borderless form. The Vista/Win7 Snipping tool works that way. You'll find the code you need to get this started it in my answer in this thread.
The other, perhaps more likely to be used by Jing, is similar to what Spy++ does, allowing the user to move the mouse and draw a selection rectangle around the window. Its advantage is that it can deal with windows resizing or disappearing while you've got the tool running. You implement it by using a topmost form the size of the screen that has its TransparencyKey property set to the value of the BackColor. Fuchsia is a popular choice. You can draw on this form with the OnPaint() method, the drawing appears on top of all the windows. You'd need some P/Invoke (GetWindow) to iterate the underlying windows in their Z-order to know which window the user is pointing at. GetWindowRect() to get the window rectangle. Plus some hassle to deal with Aero lying about the border size.
You can find sample code to get you started on that technique in my answer in this thread.
Simple question. How can I change the icons of the close, minimize, maximize buttons. Can I do this in Winforms and WPF?
These Icons, the caption, and the border on your window are all drawn while processing the WM_NCPAINT message. So, the way you take over drawing this is by handling this message.
But you don't have access to the state information about the icons (i.e. which button you should draw in it's pressed state because the user is currently clicking on it.). You dont even know where exactly the mouse handling code thinks these icons are.
So to take over non-client paint, you also need to take over non-client mouse handling, and the whole problem just snowballs until you've written thousands of lines of code and your window still doesn't behave quite right when the user tries to drag it, etc.
And that's in unmanaged code, in managed code (C#/.Net) this is even harder because you also have to do interop to get to some of the APIs you need to use.
So the answer is: Yes its possible, but its harder in WinForms and WPF than it is in C++, and those that have attempted it are all bald now.
The real answer is that you shouldn't do this. Users expect all applications to work and look the same. Making them try an figure out what spiffy new icon you use means minimize is likely to make them unhappy.
Doing this isn't difficult but it is a lot of work - you have to basically replace the window frame and handle everything yourself, there is a lot of functionality in the default window frame you have to rewrite - you also have to write different code for Vista/7 with Aero enabled.
In WPF you use the various techniques in http://blogs.msdn.com/wpfsdk/archive/2008/09/08/custom-window-chrome-in-wpf.aspx
In WinForms you use the same basic techniques but I don't know of a page that summarizes all the details like the link above.
In wpf, you can set WindowStyle="None" for your Window and then set a custom TitleBar for that, with minimize, maximize and close button. I have done this earlier. You need to do some event handling to perform minimize, maximize, close, drag etc.
Yes, you have to create your own window style. Refer to FluidKit, GlassWindows for example.
If you want to control the look of those buttons, you'll have to create your own. This is one value of using Windows features to write windows applications (they come with a standard look and feel).
Assume i have an empty form 100px by 100px at 0,0 coordinates on the screen. It has no border style. Is there any way to have this positioned BEHIND the desktop icons?
I would assume this would involve the process Progman because thats what contains the desktop icons. But no matter what i try... getting window handles and changing parents etc, i cant seem to get the window to appear behind the icons.
Any ideas?
Essentially you want to draw on the desktop wallpaper. The desktop hierarchy looks like this:
"Program Manager" Progman
"" SHELLDLL_DefView
"FolderView" SysListView32
It's the SysListView32 that actually draws the desktop icons, so that's what you have to hook. And you can't just stick your form on top of it; you have to grab a WindowDC to that handle and draw on the DC.
It can be done - it has been done, but you're going to be using a lot of interop. Forget about doing this with a traditional Winforms Form. I don't think I've even seen it done in C#, although somebody did it in python, if that helps. I'm not a python coder myself, but the code is pretty short and easy to understand.
There is a solution to this problem, at least for Windows 8. I postet it in form of an article on CodeProject, so you can read about it here:
http://www.codeproject.com/Articles/856020/Draw-behind-Desktop-Icons-in-Windows
This works for simple drawing, windows forms, wpf, directx, etc. The solution presented in that article is only for Windows 8.
Google-fu led me to this MSDN forum question:
http://social.msdn.microsoft.com/Forums/en/winformsdesigner/thread/c61d0705-d9ec-436a-b0a6-6ffa0ecec0cc
And this is a blog post regard the major pitfalls with using GetDesktopWindow() or dealing with the desktop handle (as per your other question: C# Position Window On Desktop)
http://blogs.msdn.com/oldnewthing/archive/2004/02/24/79212.aspx
You also don't want to pass GetDesktopWindow() as your hwndParent. If you create a child window whose parent is GetDesktopWindow(), your window is now glued to the desktop window. If your window then calls something like MessageBox(), well that's a modal dialog, and then the rules above kick in and the desktop gets disabled and the machine is toast.
Anyway, I suspect that it probably CAN be done, but whether you should is another question.