Windows: Windows

Starting from the previous article I reproduced how to program the Windows SDK, I hope to add some background knowledge about Windows programming. This is because when I first introduced the "SW System window class", I assumed that the reader had some knowledge about Windows interface programming.

In the previous article, we explained how to use Windows programming. However, I am used to "Breaking the sandpot and asking the truth". Many things rely on "Understanding" instead of "Recording ". So let's talk about why Windows SDK looks like this now.

A classic winmain function usually consists of three steps:

1. Register the registerclass ).
2. Create and display a window (createwindow and showwindow ).
3. Messageloop ). That is, get the message, dispatch the message, and process the message.

The window program needs to "Create and display the window", which is obvious. Message loops are also easy to understand, and we have described them in a very detailed description in "sw system introduction.

I believe the most confusing thing is: what is the concept of "window class? Why registerclass?

Someone replied: the "window class" is a common property of the same type of window.Shared data.
Someone replied: the "window class" belongs to the same type of window.Default data (attribute).

The answer window data isShared data. Because we know that each window has its own menu, icon, Window Process (windowproc, this is the most important) and so on. They do not have a shared relationship. The answer is:Default data (attribute), Correct, but did not answer why the default attribute is required, not to mention the more important reasons.

Let's take a look at the prototype of createwindow and createdialog:

Hwnd createwindow (
Maid,
Lptstr lpwindowname,
DWORD dwstyle,
Int X,
Int y,
Int nwidth,
Int nheight,
Hwnd hwndparent,
Hmenu,
Hinstance,
Lpvoid lpparam
);

 

Hwnd createdialog (
Hinstance,
Lptstr lptemplate,
Hwnd hwndparent,
Dlgproc lpdialogfunc
);

Why does a normal window not be created like a dialog box (DIALOG), but the window process (windowproc) is directly passed in, even all the data related to other window classes is passed in directly at createwindow? Someone may say that this is to reduce the number of parameters in createwindow. -- Well, I really don't know how to prove this. However, I stubbornly think that the reasons below should be sufficient.

Have you heard of the serialization (searialize) technology? Some readers immediately replied: Yes, this is a technology in MFC that writes objects to the disk and reads and restores these objects from the disk. I will give it 4 points (out of 5 points ). Yes, serialization (searialize) isObject Persistence and Restoration. However, this is not just the beginning of MFC, but a technology that turbo vision already has under DOS.

What is the dialog box? The dialog box is a special window that supports the serialization (searialize) technology. It restores (creates) Its subwindows from the resource during initialization. However, unlike general serialization (searialize), the object persistence process is not a dialog box, but a dialog box editor.

Undoubtedly, visualized programming based on the dialog box is quite friendly. From the perspective of visual programming, we need to support serialization and create a window from the disk. Let's look back at the prototype of the createwindow function. You will find that these parameters are "serializable (portable. Moreover, you immediately realized that the window process (windowproc) cannot be serialized.

We know that the serialization technology requires the runtimeclass technology to dynamically create objects. The so-called runtimeclass technology is nothing more than creating a ing between a unique class ID (such as the class name and guid) and a class creation function (other ancillary data is relatively secondary.

Now the key is: to support restoring window objects from a disk, Windows needs to introduce the window class name and establish its ing with the window process (windowproc. -- This is exactly the meaning of registerclass. In registerclass, other window class attributes are secondary and may be correct. These attributes exist only to reduce the number of parameters of the createwindow function.

Supplement: Click here to learn about the implementation mechanism of runtimeclass and searialize.

Supplement: the question of sharing GDI resources is also raised by the gentleman. It should be acknowledged that, as I said earlier, "window data isShared dataThis is an arbitrary statement. Yes, windows must face the problem of sharing GDI resources. Resource Sharing exists in different windows. A more reasonable statement is that each window can independently set its own menu, icon, and window process, but the menu/icon and other GDI resources can be shared. As we know, Windows's sharing policy for GDI resources is that Windows do not have the ownership of GDI resources (menus/icons, etc.), and users must be responsible for the life cycle of the GDI resources. In other words, a window only has a menu/icon handle.