DUI framework development series: Advantages and Disadvantages of visual interface editing tools based on controls combination or inheritance

Hello everyone, all the points I want to introduce are some of the valuable questions that have been discussed during the development of Windows touch screen DUI open-source framework constvar (click to download the Code.

 

This article will discuss the relationship between visual interface editing tools and control implementation methods.

 

The visual interface editing tool is an indispensable tool of the directui interface framework. It should be an important part of the entire framework. Visual development tools in vs are very powerful. For example, the interfaces dragged out by MFC are close to what you see is what you get, and the addition, deletion, modification, and query of message event Method attributes are very convenient, and the interfaces are also very unified, it can be said that we have done a very good job. To tell the truth, if the tool software does not require the interface, brother does not want to use any DUI framework, directly on the MFC is the fastest and best to use.

 

However, the problem with MFC is that the appearance and form of custom controls are very troublesome. The cost of self-painting is very high and inflexible, and it is easy to cause code duplication, the self-painting project of MFC is usually surrounded by multiple controls, such as GDI painting, rigid controls, and poor adaptability to changes. These are related to the implementation of the MFC control, that is, all controls are implemented in inheritance mode. For more information, see the inheritance tree of classes on csdn. controls such as ctreectrl, ccombobox, and clistctrl that look like "complex appearance" are derived from cwnd, and cwnd is important, it is because it is the base class of all controls. Derived from cwnd, it means a new control. If a control is derived from cwnd, even if the control combines more control objects derived from other cwnd, it is also a control, not just a combination.

 

The problem is that a "new control" has its own attributes and default form, so it must have a corresponding function on the Interface editing tool to create this type of control. Open the control toolbox of MFC. All the controls described above can see their own creation tools, and these controls are dragged to the interface to have their own forms. However, in this one-to-one relationship, the newly added control needs to be added to its own "toolbox", that is, the new control needs to correspond to an implementation in the interface editing. In this way, the interface editing tool will be constantly modified.

 

For example, in MFC, I implemented a Custom button control derived from cbutton, but it also overlays a cedit control to display a certain state of the button, just like a seemingly simple custom control, the toolbox of MFC cannot be dragged out. Only by dynamically creating or creating a button and cedit respectively, because the toolbox of MFC does not implement our custom controls. This problem arises. If the user is forced to create dynamically, it means that the visualization tool cannot edit these new controls, that is, it is "invisible". If the following method is used, the widget is not a whole, which means that the Multiple widgets must be logically associated in the code, and the new properties of the new widget cannot be set during interface editing, this is against the consistency with other existing controls, that is, it can be used if it is implemented. If it is not implemented, it is only manual. This is a pitfall.

The MFC brother can't touch it, but the framework he wrote can still be moved. Add the new control to the toolbox and implement it. Yes, yes, but the control library based on the inheritance implementation will eventually become very bloated to adapt to the changing interface requirements, often, a new control category will be created to describe these differences due to some small form changes, because the base class is used in many places and cannot be moved, the previous implementation may be unstable. Or copy a class and make some changes to implement a similar form of controls. These methods are indeed very cumbersome, and eventually make the code extremely ugly and annoying. Even if the maintenance personnel are patient, what should I do with the interface editing tool? Add a control and modify it? If this parameter is left blank, it may cause pitfalls everywhere.

 

Although the above uses MFC as an example, the same is true for directui. First, this problem occurs when inheritance is used to implement new controls.

 

To avoid this problem, constvar adopts a combination of controls (or complex controls. First, implement several very limited basic controls on the Interface editing tool, 3-5 are enough. Other widgets have these basic controls. Of course, complex controls, that is, any new controls must have their own logic to combine these widgets. For example, a clistctrl may be composed of a series of BTN and static values. In code, clistctrl is no longer derived from cwnd and does not need to be derived from any class. It only needs to combine these widgets and control them. The advantage is that the interface editing tool does not need to implement a corresponding function after any controls are added. The combination of these components has a strong adaptability. The disadvantage is that these components are independent individuals and are independent basic controls with their own properties. They cannot be displayed as a new control during interface editing, that is, the interface editor can only drag a single interface appearance, and its soul must be controlled by code. But this is much simpler and more powerful than the first one.

 

In general, if you can control controls that are no longer added within a limited set and all of them are implemented on their interface tools, inheritance of this implementation still has a little advantage, but in fact the operability is very poor, basically impossible. Therefore, this interface editing tool often ends up.

The combination solves this problem, but the WYSIWYG is slightly less than one or two. In addition, the initialization of various attributes of the new control can only be reflected in the Code, both the auxiliary code, or other work, to put it bluntly, there is no such thing in the interface editing work. You need to set those attributes to think of additional methods.

DUI framework development series: Advantages and Disadvantages of visual interface editing tools based on controls combination or inheritance