I have an application that I want to stick to the desktop. Stick to the desktop means that every time that someone click windows+D or the show desktop icon the desktop will appear with the application on it.

The user can locate the application on the desktop and change the location at any time but it always remains on the desktop.

We manage to do it on XP by setting the application’s parent to be the desktop using the winAPI methods SetParent (this .Handle, FindWindow ( "Progman " , null ));.

On Vista we manage to stick it to the desktop, whenever the desktop gets focus, it draws a gray background around we window. this background doesn't disappear when my window is moved, leaving ugly squares on the desktop. when I click Windows+D they all vanish.
Note that this doesn't happen on XP at all.

The client is based on .NET 3.0 and WPF .

Any idea why it happens and how to solve it?

Hi Edos,

After consulting with our internal resources, I got confirmed that there is no supported way to do what you want. My previous post mentioned the Gadgets in Windows Vista/7 did it right because the Desktop and Gadgets know each other so when Win+D is pressed, the Desktop will bring the Gadgets up together. But for 3rd party windows, no way.

I'd suggest you pick the more appropriate tech to implement what you want starting from Vista -the Windows Sidebar Gadget. It will give you the exact behavior you're looking for and more importantly, it issupported by us.

Your current approach works on XP, that's fine, but as you've already seen, no guarantee it works on future platforms. Only by using the supported techniques, you'll get a much better compatibility story.

If you have any further questions, please let me know.

Thanks,
Jie
MSDN Subscriber Support in Forum
If you have any feedback on our support, please contact msdnmg@microsoft.com

---

Please remember to mark the replies as answers if they help and unmark them if they provide no help.

If you have any feedback, please tell us.

The CodeFx Project
My Blog (in Simplified Chinese)

Hi Edos,

From your code above I'm a little bit confused- you said SetParent(this.Handle ...), however, if your application is based WPF, a WPF window just doesn't have a Handle property.

So could you please clarify: is your window a WinForm window or a WPF window?

Thanks,
Jie
MSDN Subscriber Support in Forum
If you have any feedback on our support, please contact msdnmg@microsoft.com

---

Please remember to mark the replies as answers if they help and unmark them if they provide no help.

If you have any feedback, please tell us.

The CodeFx Project
My Blog (in Simplified Chinese)

Hi guys,

Actually Wang is not completely right.

WPF windows must have an IntPtr handle to operate and interop with the O.S.

WPF wraps the window handle so it is less accessible, but it is there.

To get the window handle in a WPF window just use:

"IntPtr Handle = new WindowInteropHelper(this).Handle;"

where ever you need to use the window handle, but not before the Window_Loaded event of your WPF window (Handle is 0 before that).

It is very common to add a "Handle" property of type "IntPtr" to your WPF window so it could be used later on.


Don't have an answer for Edos but i will check in to it.

Bye

Hi guys,

Actually Wang is not completely right.

WPF windows must have an IntPtr handle to operate and interop with the O.S.

WPF wraps the window handle so it is less accessible, but it is there.

To get the window handle in a WPF window just use:

"IntPtr Handle = new WindowInteropHelper(this).Handle;"

where ever you need to use the window handle, but not before the Window_Loaded event of your WPF window (Handle is 0 before that).

It is very common to add a "Handle" property of type "IntPtr" to your WPF window so it could be used later on.


Don't have an answer for Edos but i will check in to it.

Bye

Then any statements in the form of "A WPF window doesn't have a ??? property" will be false according to the logic above - it doesn't exist, you add it and of course now it's there.

Anyway, I don't want to argue about this. All I want is to clarfiy with Edos what exactly that window is, WPF or WinForm. Besides, Edos need to post the question in the WPF forum if he is working on a WPF window.

---

Please remember to mark the replies as answers if they help and unmark them if they provide no help.

If you have any feedback, please tell us.

The CodeFx Project
My Blog (in Simplified Chinese)

I think we can do this without having to set the window as Progman's child.

When Win+D is pressed (or show desktop command), the windows which can be minimized will be minimized, then the Desktop window is brought up to top so it covers other windows thatare not minimizable - topmost windows are of course still on the top.

So we need to remove the Minimize button from the window, so when Win+D is pressed, the window doesn't get minimized.

Then we need to find out how to keep the window's zorder in front of the desktop window when the desktop is brought up.

In Windows 7 the gadgets windows do a good job. I'll try to find out how they did it.

Regards,
Jie
MSDN Subscriber Support in Forum
If you have any feedback on our support, please contact msdnmg@microsoft.com

---

Please remember to mark the replies as answers if they help and unmark them if they provide no help.

If you have any feedback, please tell us.

The CodeFx Project
My Blog (in Simplified Chinese)

Thanks fortrying to help on my issue.
For your question, Im using WPF windows.

Hi Edos,

After consulting with our internal resources, I got confirmed that there is no supported way to do what you want. My previous post mentioned the Gadgets in Windows Vista/7 did it right because the Desktop and Gadgets know each other so when Win+D is pressed, the Desktop will bring the Gadgets up together. But for 3rd party windows, no way.

I'd suggest you pick the more appropriate tech to implement what you want starting from Vista -the Windows Sidebar Gadget. It will give you the exact behavior you're looking for and more importantly, it issupported by us.

Your current approach works on XP, that's fine, but as you've already seen, no guarantee it works on future platforms. Only by using the supported techniques, you'll get a much better compatibility story.

If you have any further questions, please let me know.

Thanks,
Jie
MSDN Subscriber Support in Forum
If you have any feedback on our support, please contact msdnmg@microsoft.com

---

Please remember to mark the replies as answers if they help and unmark them if they provide no help.

If you have any feedback, please tell us.

The CodeFx Project
My Blog (in Simplified Chinese)