Make MiniGUI code more like MFC

All windowsProgramAlthough MFC may not be the best GUI library, it is undeniable that Microsoft's work on MFC makesCodeIt is easier to maintain and read, especially when you have a lot of interface control code in large projects. At present, there are many GUI Libraries in the embedded application development field, and MiniGUI has been widely used as a domestic GUI library in the embedded field. Currently, MiniGUI has two major disadvantages: 1. How to Make the interface development more visualized; 2. How to Make the code structure easier to maintain when developing a large project. Although the company hasn't provided better support in this regard, we should try to solve this problem as a programmer! Convenience for others means convenience for yourself!

First of all, I want to talk about the control array layout problem. The mainstream two methods are: 1. Separate Control arrays by using the corresponding file of the form, put the array code of all controls of the current form into the form file; 2. Put all controls in one. in the c file, I personally advocate the latter method. In this way, the control can be easily transplanted and modified under different display screens of the program, in addition, it is easier to find the corresponding control array. I usually place all the control arrays to resources. in the c file, place the Control ID definition to resources. in the H file, you can easily locate and modify the control code by adding appropriate annotations.

The second is the code style in control programming. First of all, we use C for development because MiniGUI is written in C, therefore, I advocate C-style comments /**/. In fact, there is not much problem with annotations, as long as the style is unified. Annotations can also make us better understand others' ideas, And/**/is easier to process block annotations. Friends who have written the MiniGUI program may be clear that all the events and behaviors in the MiniGUI code are handled through messages, the processing of messages uses a lot of case work, so when a project reaches a certain level, you will find that, you don't want to take a look at the code of the Form file consisting of 40 controls at all. A large number of cases will cause you a headache, if the next programmer modifies your code, he will first complain. So, we need to do some additional work to make this code easier to read. In my work, I usually use macros to solve this problem. By comparing the following two sections of code, you will find that the second section of code is more likely to be MFC:

1.
Static int dialogproc (hwnd, int message, wparam, lparam)
{
Switch (Message)
{
Case msg_initdialog:
/* Initialize the processing code */
Break;
Case msg_command:
Switch (wparam)
{
Case idc_button_btn:
/* Button processing code */
Break;
}
Break;
}
Return defaultdialogproc (hwnd, message, wparam, lparam );
}

2.
Static void dlg_initialize (hwnd, int message, wparam, lparam)
{
/* Initialize the processing code */
}

Static void btn_clicked (hwnd, int message, wparam, lparam)
{
/* Button processing code */
}

Static int dialogproc (hwnd, int message, wparam, lparam)
{
Setup_dialog_proc ()
Return_message_event (msg_initdialog, dlg_initialize, 1)
Setup_control_map
Map_control_to (idc_button_btn, btn_clicked)
End_control_map
End_dialog_proc ()
}

This code looks strange, but it is actually an improvement of the previous code. I used the following macro
# Define setup_control_proc (ctrl_id) Case (ctrl_id ):\
Switch (Message ){
# Define end_control_proc (default_proc) Default :\
Return (* default_proc) (hwnd, message, wparam, lparam );\
}\
Break;
# Define do_message_event (msg_type, do_func) Case (msg_type ):\
(* Do_func) (hwnd, message, wparam, lparam );\
Break;
# Define return_message_event (msg_type, do_func, Reval) Case (msg_type ):\
(* Do_func) (hwnd, message, wparam, lparam );\
Return (reval );
# Define setup_dialog_proc () Switch (Message ){
# Define end_dialog_proc () Default :\
Return defaultdialogproc (hwnd, message, wparam, lparam );\
}
# Define setup_control_map case msg_command :\
Switch (wparam ){
# Define end_control_map default :\
Break ;\
}\
Break;
# Define map_control_to (ctrl_id, event_func) do_message_event (ctrl_id), (event_func ))
Using this kind of tips can make MiniGUI code easier to read when it is getting bigger. When using the macro above, note that if the dialog box message needs to be processed by default, add defaultdialogproc (hwnd, message, wparam, lparam) at the end of the corresponding function );
Of course, the above macro is not designed for the original form message. If you are interested, you can improve it. I hope everyone can work smoothly.