An assembly tutorial with a dialog box as the primary interface for an application

Now we're going to start learning some interesting parts of GUI programming: applications that use dialogs as the primary interface. We'll cover the process in two separate classes.

Theory:

If you pay close attention to the previous program you will find that you cannot press the TAB key to jump from one child window control to another, and if you want to transfer it, click on it with the mouse. This is not friendly to the user. The other thing is that if you change the background color of the main window from white to Gray as you did in the previous lesson, you must categorize all the child windows in order to change the window controls seamlessly. The reasons for this inconvenience are that the child window controls were originally designed for the dialog box, and the background color of the child window controls is gray, and the background color of the dialog box is gray, so that they are already coordinated, without the programmer adding other processing. We need to know what the dialog box is before we go into the discussion dialog. A dialog box is actually a window with a lot of child window controls, Windows has a management program inside the dialog box that handles the input focus from one child window space bar to another child window control, and presses the ENTER key equal to when pressing the TAB key. The previous child window control with input focus clicks on the mouse and so on, so that the programmer can focus on their logical affairs. dialog boxes are used primarily as input and output interfaces, and people don't have to know how they work inside, and they just know how to interact with them. This is also the so-called information hiding in object-oriented design. As long as the implementation of the black box is perfect enough, we can safely use it, of course, we must emphasize that the "black box" must be perfect. The implementation within the WIN32 API is a "black box". Oh, as if our discussion is somewhat topic, now let's get back to the point where the dialog is designed to reduce the programmer's workload, and if you put a child window control in the window, you have to handle the key logic and the window process of the detail. If you put it in a dialog box, the Chores dialog box will work itself out, as long as you know how to get the data that the user has entered and how to put the data into the child window control. The dialog box is defined as a resource in the program, and you can write a dialog box template in the script file that contains the features of the dialog box and the child window, and then edit it with the resource editor. It is important to note that all resources must be placed in the same script file. Although you can edit script files with a text editor, it is much more convenient to use some visual editors when you want to adjust the position of the child window control to include some coordinate values. Typically, you will have a resource editor in the compiler's development package that you can use to generate a template and then delete some child window controls. There are two main types of dialog boxes: Modal Dialogs and modeless dialog boxes. The modeless dialog box allows you to switch the input focus to another window (the same application) that does not need to be closed. Like the Find dialog box in Ms WORD. There are two types of modal dialogs: Application Modedialog boxes and system dialogs. The Application dialog box does not allow you to switch input focus in this application, but you can switch to other applications, and the System dialog box must be responsive to the dialog box or you cannot switch to any application. To create a modeless dialog box, invoke API function Createdialogparam, and create a modal dialog box to invoke the API function Dialogboxparam. Where the difference between the application-mode dialog and the System-mode dialog box is different from the style parameter, to create a system-mode dialog This parameter must be "or" ds_sysmodal the flag bit. Call the function Senddlgitemmesage in the dialog box to communicate with the child window control. The syntax for this function is as follows:

SendDlgItemMessage proto hwndDlg:DWORD,\
idControl:DWORD,\
uMsg:DWORD,\
wParam:DWORD,\
lParam:DWORD

The PAI function is useful for sending to a child window control. For example: If you want to get a string in an edit control, you can do this:

Call SendDlgItemMessage, Hdlg, Id_editbox, Wm_gettext, 256, ADDR Text_buffer

To send those messages specifically, you should inquire about the WIN32 API reference manual. WINDOWS also provides several functions for fast access to control data. For example: GetDlgItemText, CheckDlgButton and so on. This way, you can get information without having to query the wparam and lparam parameters of each message. You should use these API functions as much as possible, making your code easier to maintain in the future. The management function of the dialog box sends some messages to a specific callback function: the dialog procedure handler function, which is in the form:

DlgProc proto hDlg:DWORD ,\
iMsg:DWORD ,\
wParam:DWORD ,\
lParam:DWORD

The function's format is very similar to the window's procedure function, except that the return value is ture and false, rather than HRESULT, the dialog manager that exists inside Windows is the dialog box's Real window procedure function. It will pass some messages to our window procedure function. So when our window process function processes these messages, it returns TTRUE, otherwise it returns false in EAX. This also means that our window procedure function does not call the DefWindowProc function when it accepts messages that it does not process, because it is not a real window procedure function. There are two uses for a dialog box: one is to use it as a main window, and one that is used as a input. In this lesson we will demonstrate the first usage. The use of the dialog box as the main window has two meanings: 1. You can call the RegisterClassEx function to register the dialog box template as a window class. The behavior of this dialog box is similar to a normal window: it handles all of the messages by specifying the window procedure at the time the window is registered, and the advantage of using the dialog box is that you do not need to display the child window control, Windows itself will help you create it, and it will also help you handle all the key logic. Alternatively, you can specify the cursor and icon in your window class structure, 2. Your application creates a dialog window without a parent window, in which there is no need for a piece of code to process the message loop, because all messages are sent directly to the dialog box process handler so that you do not register a window class. In this lesson, I will first use the first method and then use the second method.