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.
Related
For a while now I have attempted to get into UI design with WPF. My main goal is to create a good-looking application in a borderless window, like for example:
I made this example using the MetroUI framework. While this framework does the trick on borderless window functionality, it also does way too much for my tastes, custom controls, skins, animations, etc. I just want a borderless window and decide everything else myself.
I've searched stackoverflow a lot, and tried a fair amount of frameworks, but nothing seems to suit my needs.
Basically, I would like to have a borderless window with FULL windows functionality (drag to sides to pin, only show shadow if operating system settings has it on, etc etc).
Putting WindowStyle to None but keeping AllowsTransparency at False in order to preserve the original window chrome makes most if not all of the functionality I am seeking for work. However, the obvious problem here is: the window chrome is still there.
This looks like this:
To finally ask my question:
Can we keep all the current functionality that this window chrome provides, but somehow make it invisible (yet keep the dropshadow it provides) ? I can live without the dropshadow but it would be a nice bonus.
Or to ask a more broad question: is there any framework / pre-made project, that simply ONLY handles making a borderless window work properly and no other additional controls, skinning, ... ?
The more time I put into this the more it seems making borderless windows with WPF is simply incredibly clunky and I am getting rather unmotivated on my entire project because of this.
Thank you
See my answer on the following thread, it pretty much sums up all the window issues at once. Hope it helps!
WPF Borderless Window issues: Aero Snap & Maximizing
I want to make a menubar like window taskbar in C# but I'm wondering how can I make the form stay on the top of the screen and other program will not taped over it just like the window taskbar and when the mouse hover on a icon it will show a form like this:
I have made it like this:
And This is what I want
Windows has a facility for this, allowing you to basically create pseudo-taskbars that dock to the side of the screen and are always visible. It was used by the Office team (possibly publically documented for the Office team?) a long, long time ago to create a desktop toolbar.
Anyway, they are called Application Desktop Toolbars (or "AppBars"), and the documentation is here. To register one, you call the SHAppBarMessage function with the ABM_NEW message. Complete sample code is available in the linked documentation, unfortunately it is in C++.
To use this from a C# application, you will have to P/Invoke. As far as I know, it is not wrapped by the .NET Framework anywhere, probably because it never gets used by anyone anymore. This CodeProject article appears to have the necessary P/Invoke definitions written out. I can't vouch for their correctness, but armed with the documentation and that as an example, you should be able to cook up a working demo.
There is another CodeProject article here, written by Arik Poznanski as part of a series on using shell features from C#. It looks much more thorough, probably more than you need.
Set the property Form.TopMost unless you have other programs creating topmost windows. Doh!
I've been googling a lot for this one and I can't seem to find anything. Maybe it's the way that I'm wording it. So basically what I'm looking to do in C# using Windows Forms, is create a form and have it essentially take the shape of the taskbar and do the same functions as the taskbar, but it will sit above the task bar or at the top of the screen.
It can't be "ON TOP" (I'm not trying to block user buttons like the close button of a program they are using).
Autohide would be a plus.
This is the main thing I'm after:
It needs to act just like the task bar. When you maximize any other window, the taskbar does not go over the top of the window, even though it is set to "on top".
You'll want to use an Appbar to do this:
http://msdn.microsoft.com/en-us/library/cc144177.aspx
For more information, check out here and here and here.
If you don't want to deal with C++ and Native Code (as #FKunecke correctly proposed) then you'll not find anything predefined for this. What you can do is create a form for your bar and make the visualization calculations by hand, then you can set the screen location of it. That's all. Not forcing the bar form to stay on top will not hide the other app forms so you'll get that for free.
Now, to fully implement what you want there are some problems you need to deal with, such as Taskbar location and height. Then you'll need to use some native code tricks.
How to put a C# programm (ex WPF or WF) under desctop Icons (like a wallpaper)?
I want my Old Good XP Active Desktop made by a some open source C# programm on my Win 7!)
Something like this - Fences .
They have there "windows" appearing underneath icons. I do not want to manage Icons - just put my window under them... BTW any one knows about such operations in other OS’s (Mac etc)?
And I DO NOT WANT TO MANAGE ALL THE ICONS ON MY OWN LIKE bumptop
I think it is quite possible, try this:
Find handle to window with the class "Progman".
Create some window in your application (or, perhaps, in some separate application, you will see the purpose later) and turn off its borders.
Set the parent of the newly created window to desktop handle.
Set the parent of "Progman" window you have found previousely to the window you created.
Desktop will be put on a window owned by your application and it will be possible to manipulate it in the way you want (namely, put something under it).
Also, do not forget to restore desktop's parent when application owning it is closed.
Look for FindWindow, GetClassName and SetParent at http://www.pinvoke.net/
Short answer is you can't really do it (in managed C# anyway). If it's possible, you would need to use Interop, and you'd likely be calling something that Windows doesn't offer as an API.
... although... as Ole Jak mentioned, Stardock looks to be doing it somehow...
The desktop is its own contained item. The same process handles the icons and the wallpaper "behind" those icons.
You are allowed to change the wallpaper to a different image, and you used to be able to create an Active Desktop where HTML content would be displayed, but this was discontinued in Vista.
What are you actually trying to do? Maybe there's another way to achieve a similar result?
There was DreamScene for vista. You could put a video as explorer background. I dont know if you could run a C# program to output the background video.
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.