Discussion of article "Graphical Interfaces II: the Separation Line and Context Menu Elements (Chapter 2)"

[MetaQuotes]

New article Graphical Interfaces II: the Separation Line and Context Menu Elements (Chapter 2) has been published:

In this article we will create the separation line element. It will be possible to use it not only as an independent interface element but also as a part of many other elements. After that, we will have everything required for the development of the context menu class, which will be also considered in this article in detail. Added to that, we will introduce all necessary additions to the class, which is the base for storing pointers to all the elements of the graphical interface of the application.

The first article Graphical Interfaces I: Preparation of the Library Structure (Chapter 1) considers in detail what this library is for.

Developing the Class for Creating a Separation Line

In a context menu, besides different types of menu items, we can often see one more interface element - a separation line. This element can be encountered not only in context menus. For instance, the status bar of the MetaTrader trading terminal and the MetaEditor code editor have vertical separation lines. That is why we will create a separate class for this object so it can be used in any other control or even used as a separate element of the graphical interface.

To give an illusion of volume, a separation line must consist of at least two parts. If one line is lighter than the background and the other one is darker, this will create a visual effect of a groove on the surface. There are two ways of creating a separation line: (1) from two primitive objects of the CRectLabel type, which are already present in the Objects.mqh file or (2) create an object of the OBJ_BITMAP_LABEL type and use it as a canvas for drawing. Let us use the second option. The standard library suggests the CCanvas class for drawing. This class already contains all necessary methods for drawing simple geometrical figures, which significantly simplifies the implementation of the intended design and will save us a lot of time. 

The CCanvas class has to be embedded in a way so it can be used in a similar way to those primitive objects, which are already present in the Objects.mqh file. This can be easily achieved by making the CCanvas class derived from the CChartObjectBmpLabel class. A little change has to be introduced in the code of the CCanvas class so there are no errors or warnings later when the program is compiled. This is because in both the CCanvas class and the CChartObject class, which is the base class for the CChartObjectBmpLabel class, there is the m_chart_id field (variable). As a result, the compiler will give a warning that a variable with such a name already exists:

Author: Anatoli Kazharski

[Igor Volodin]

Is there a mechanism for binding/delegating actions/commands to different controls? For example, to a button in the toolbar and a context menu item? The "command" pattern would be suitable for this. At the same time, it is possible to implement Undo/Redo mechanism through storing in the history of executed commands, saving the initial values of the recipient.

It is also good to introduce the concept of a model, which is listened to by this or that control (pattern observer). This will allow all controls in the interface to react transparently to changes in the model.

For example, until the chart model has not been initialised by the user, all controls related to the chart management have a disable view. This eliminates the need for direct access to the controls and the logic responsible for their behaviour in certain cases.

[Anatoli Kazharski]

Igor Volodin:
Is there a mechanism for binding/delegating actions/commands to different controls? For example, to a button in the toolbar and a context menu item? The "command" pattern would be suitable for this. At the same time, it is possible to implement Undo/Redo mechanism through storing in the history of executed commands, saving the initial values of the recipient.

It is also good to introduce the concept of a model, which is listened to by this or that control (pattern observer). This will allow all controls in the interface to react transparently to changes in the model.

For example, until the chart model has not been initialised by the user, all controls related to the chart management have a disable view. This eliminates the need for direct access to the controls and the logic responsible for their behaviour in certain cases.

In the current version of the library in some cases the exchange of commands between elements is implemented through custom events. The next article will tell more about it.

As for additional mechanisms, it is all negotiable. After the publication of the whole series, you can go through all the items of the scheme and make a list of what should be changed or added, if there are arguments why it would be better/reliable/convenient, etc.

I may have misunderstood the question. Then you need clarification on what exactly you need to get and what it should look like.

[Dmitriy Konogorov]

Why an array of variables ?

color             m_area_color_array[];

And in the CContextMenu() constructor you need to set the m_item_Ysize variable to a size larger than zero by default.