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.
Related
This is only an issue if you have Drop Shadows turned off in appearance settings.
I noticed some of our applications form windows had no borders. Specifically they have been missing the 1 pixel thick border for the left part, right part and bottom part of the form window. All of the forms had in common that they were using FormBorderStyle FixedToolWindow or SizableToolWindow. When it is like this it is hard to distinguish where one dialog stop and another one begins.
We find it plausible that some of our users will have their computers set up like this without the ability to change it.
Is there a way to get the dialog windows looking better without doing anything crazy like manually drawing all borders?
Quoting part of a comment by Hans Passant:
By design for Win10, the left/bottom/right borders are transparent. Still quite visible against the large drop-shadow, so visible that is hard to tell that the border is transparent...
Our application has its own grahpical style that made it especially hard to distinguish where one dialog stops and the other one begins.
The quick solution for us was to stop using FormBorderStyle FixedToolWindow or SizableToolWindow.
Long term we are going trough all our dialogs and the graphical style of our application to make the dialogs more easily distinguishable from each other with or without borders.
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.
I would like to remove the resizing border from my WPF custom window.
I already found that I have to handle the WM_NCCALCSIZE message and return 0.
That removes the border and aligns the window to the top left corner of the window.
The problem is that by doing so, the client area increases and the WPF root control doesn't.
That creates black edges on the left and bottom sides of the window that I would like to get rid of.
I'm using VS2010 C# Windows XP and would like this to work under both Windows XP and Windows 7.
Thanks in Advance.
EDIT:
I found out what is causing the black edges, they are the window behind.
Now it seems that the problem is with the root element of the window not occupying the whole window. When I set its margin to negative values it draws over the black area. Apparently the layout pass is ok and the desired size is the same as the window but the render size is different.
I also found out that the whole problem could be solved by removing WS_THICKFRAME from the window style. The problem with that is the resizing functionality that is enabled only when WS_THICKFRAME is used. I'm using WM_NCHITTEST to do the resizing and if the window knows it doesn't have a resizing border, it will shutdown its resizing functionality.
I would like to make the root element occupy the whole window to eliminate the black window background or alternatively enable the native resizing functionality without the thick frame.
Thanks.
I found the reason for that black area.
It appears that the code I was using that someone else made was causing the black area by somehow messing with the layout pass of the framework and therefore the correct size of the root element.
I handled the WM_NCCALCSIZE in another project and it worked like a charm.
After all of that, although I found the idle way to create a custom window with all of the original window functionality, I decided to use the standard window the Microsoft has to offer so that my program will have future compatibility with windows.
If someone would like the code or help with WPF window customization they can comment here and I will help so that at least all of my research won't go in vain.
Thanks for reading.
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.
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.