Embed a form in the desktop

A few days ago on the internet to see a software introduction: Can be embedded desktop, even "show desktop" will not affect this program. See what the author says as if it's magical. I'll come back for a try before week. Finally found that Windows this desktop is really complex and interesting.
The first step is to analyze the Windows desktop.
Open old Software "Spy window". Check your desktop. Gets a handle to the "SysListView32" class (The system is an XP version). Minimize it to see that the control you just obtained appears to be transparent. Because you minimize it, you can also see the desktop picture that you set up.
Re-use "Spy window" to get the control handle on the desktop (or click "Parent window" to get its parent window handle) and get a handle to the "Shelldll_defview" class. Minimize it, you can see the desktop picture is still there, is it a transparent control? Ignore it first, we continue to look for the "down". Once again get a control handle with the class named "ProgMan" on the desktop. And at this point you will find that the Spy window's Parent window button is no longer available.
This class is "progman" window "underneath" really no other windows? Press "Ctrl+alt+del" to End "explorer" in Task Manager, and then use "Spy window" to see if there is another window with a class named "#32769." Try disabling, minimizing, and hiding the window. It seems that everything is invalid.
To this, it should be said that the structure of the desktop to get clear. The equivalent of four layers in image processing, and is a transparent layer.
Sorted by class name from front to top:
SysListView32
Shelldll_defview
ProgMan
#32769
It seems that this desktop is not a general complex.
Recall the previous operation that used code to hide the desktop:
FindWindow ("ProgMan", Nil);
ShowWindow (...);
Here's the ' ProgMan ' is the third layer (we'll call them by layer) window. When the process "explorer" is closed, this window disappears, indicating that the window was established by "Explorer.exe".
The following is an operation that embeds a program into the desktop.
All you need here is one statement:
Frmmain.parentwindow:=parenthandle, where Parenthandle is the control handle of the person you want to embed.
By this implementation, you can create a form, drag into a TButton, a tedit. Writes code Frmmain.parentwindow:=strtoint (Edthandle.text) in the Click event of the button;
Next, first to embed "first floor desktop" look. Use "Spy window" to get the current desktop handle, which is the first layer ' SysListView32 '. Convert to decimal and copy to Edthandle. Click on the button.
The program is not switched to a non focus state. Click "Win+d" (Show Desktop). Whether the window still stays on the desktop.
It seems that the purpose of the beginning of the article has been realized.
A careful test of the current form is very different from the original. First, the title bar of the window is always not in focus state. The right click on the second form is blocked by the desktop.
In the third edit, the table does not show the response of the tedit itself to the message. If you click, drag, when the right click when the button, edit missing the corresponding flashing input cursor, smear the selected characters, word processing, display context menu. This is because the form does not have the focus, but the focus is not available for the Tedit control.
The way to get the first-level control handle dynamically is to:
Tmphandle:=findwindow ("ProgMan", Nil);
Tmphandle:=getwindow (Tmphandle,gw_child);
Tmphandle:=getwindow (Tmphandle,gw_child);
At this point Tmphandle is the handle of the desktop.
In this way, we can embed the form in the second layer ' Shelldll_defview '. When the second layer is embedded, you will find that. The embedded program window is missing. When we minimize the first layer, we can see that the window we are embedding exists. It was just obscured by the first floor. So, the first layer is not transparent.
After the first layer is minimized, you can see that the icons on the desktop are missing. Take a look at the first level of class name "SysListView32", you can determine that the first layer of this control is mainly to list the icons on the system desktop. Let's click the right button in the current second level. The desktop menu is out. All the information and processing are received and processed at this level. You can then use the new command to create a new document, and then restore the first level of the desktop, you can see that the new document appears.
It can be understood that the first layer is "display layer" and the second layer is "functional layer". Our form is not shown here. And the same is not the focus.
Now, embed our program into the third layer ' ProgMan ', which, after embedding, has the same result as the second layer, which, by function, should have little practical use, may just provide a container to the top two layers. Now there are two forms in the ' ProgMan ', one is the original ' Shelldll_defview ', and the other is the embedded form. But the former uses up all the viewable areas, so that the embedded form doesn't show up. This kind of situation seems to encounter usually, then we add a sentence in embedding: BringWindowToTop (frmmain.handle); try;
Oh, see what. is not the embedded window appears. Click "Win+d" to see. How is it. It's still here. If there is an icon on the desktop, then the form should be blocking the part of the icon.
The way to do this is to shrink the previous level form. Such as:
Tmphandle:=findwindow ("ProgMan", Nil);
Tmphandle:=getwindow (Tmphandle,gw_child);
MoveWindow (Tmphandle,0,20,1024,740,false);
This leaves a height of 20 pixels at the top of the form. You can put a taskbar-style form in place.
There is only one last layer of "#32769" left. As long as the system before the launch of the program does not change, the handle of this window should be unchanged (it is possible to start the system before the program has changed this handle is not changed, the specific situation has not been tried).
Embed the form in this window in the previous method.
The form is not in the focus state. As you can see, this is almost as embedded as the first layer. But let's take a look at the form. The form does not follow the mouse in real time. To take a closer look, there are two buttons on this program on the taskbar. One is the name of the program and one is the name of the window. It is a strange phenomenon that has never been seen before. Maybe we can explain it this way. The Explorer displays the form that meets the requirements on the taskbar (not toolswindows and visible). This form is compliant, and explorer puts all the windows in the #32769 window onto the taskbar, regardless of whether it is complex or not. That's why we're going to get this result.
To sum up:
The Windows desktop is divided into four tiers. If the embedded form is embedded in the third layer, and the z-axis order is moved to the top, the program will have a normal desktop embedded program. This is in line with our requirements. You can also make the form not cover the desktop icon by resizing the second level. Therefore, it is ideal to embed the form here.
The first layer of embedding is also possible. But here the window experience does not have the focal point and the use right key. So the form here is subject to a lot of restrictions.
The second layer is a place where the embedded form is not considered at all, because the form is not displayed at all. And the same as the first layer does not get the focus.
The fourth floor is an unexpected layer. The form that is embedded here displays a strange situation. The only reason we should embed is that it won't close with the end of the Explorer.exe process.

This is the code that is implemented with MFC
HWND hdesktop =:: FindWindow ("ProgMan", NULL);
Hdesktop =:: GetWindow (Hdesktop, gw_child);
cwnd* pwnddesktop = Cwnd::fromhandle (hdesktop);
This->setparent (Pwnddesktop);