Discussion of article "MQL as a Markup Tool for the Graphical Interface of MQL Programs (Part 3). Form Designer"

[MetaQuotes]

New article MQL as a Markup Tool for the Graphical Interface of MQL Programs (Part 3). Form Designer has been published:

In this paper, we are completing the description of our concept of building the window interface of MQL programs, using the structures of MQL. Specialized graphical editor will allow to interactively set up the layout that consists of the basic classes of the GUI elements and then export it into the MQL description to use it in your MQL project. The paper presents the internal design of the editor and a user guide. Source codes are attached.

Editor is designed for the classes of Standard Library interface elements. To create similar tools for other libraries, you will have to write the specific implementations of all abstract entities from the markup system proposed. At the same time, you should be guided by the implementation of markup classes for the Standard Library.

It should be noted that the "library of standard components" definition is not factually correct, since in the context of our preceding articles, we had to considerably modify it and place to the parallel version branch in the ControlsPlus folder. Herein, we are going to continue using and modifying it.

Let us list the types of elements to be suppported by the editor.

• Containers CBox with horizontal (CBoxH) and vertical (CBoxV) orientation,
• CButton,
• CEdit input box,
• CLabel,
• SpinEditResizable,
• CDatePicker calendar,
• Drop-down list ComboBoxResizable,
• List ListViewResizable,
• CheckGroupResizable, and
• RadioGroupResizable.

All classes ensure adaptive resizing (some standard types could do that at the beginning, while we had to make considerable changes for the other ones).

Editing the Form

Author: Stanislav Korotky

[fxsaber]

That was powerful!

[Sergey Pavlov]

Congratulations!!! Great job and articles.

[Реter Konow]

Finally, a decent competition (I mean the result). Now, hold on!)))))

[Реter Konow]

The visual editor should still include manual editing of elements - stretching, moving, typing text, copying and so on. Auxiliary markup is desirable.

This editor shows promise, although I have no idea how the author realises the other requirements, as I don't understand his technology. It "stood on the shoulders" of the standard library and on the one hand it gave a powerful push forward, on the other hand it makes you inherit its limitations. It's not designed for large-scale transformation... A lot of functionality will have to be added from above.

List of requirements for the future editor:

1. Manual customisation of elements.

2. Copying of elements.

3. Simultaneous property management of a set of elements.

4. Auxiliary framing.

5. Multi-window mode.

6. Creating windows of different types.

7. Support for window properties: "always on top", blocking others, with/without minimisation.

8. Parallel editing of windows.

9. Deleting windows.

That's all for now.

ZY. As far as I know, the SB controllers consist of MT-objects, which on the one hand - simplifies the system of interaction with elements and manual adjustment (a long time ago I had an editor based on MT-objects and it was not difficult to make it), on the other hand (if you accept this simplification) - takes away all the advantages of canvas (among which - speed, visual effects and much more). That is - the "doping effect" of using SB when creating an editor, severely limits its development. But, let's see...

[Реter Konow]

Interestingly, even without a kanvas, the author can do auxiliary markup if they solve the issue of manually setting up elements. That's what I've done. Of course, the markup on the canvas is visually cooler, but in the Sharpe editor, for example, the markup, though sparse, is practical. Only a couple of lines help to position controllers. I was surprised when I looked into it after I made my markup.

The taskbar needs to be made too. Preferably.

[Guilherme Mendonca]

That's very good!

Congratulations!

It's amazing how MT5 it's getting better and better with the passing time.
In the near future I think anyone will be capable to build and set up any graphic interface wich will attend your nees.  

[Stanislav Korotky]

New example of a program with GUI built by declarative MQL layout design is published in the codebase - ChartBrowser.

[Guilherme Mendonca]

Hi, 

I'm facing this kind of situation in one of my laptops.

Everything looks tiny except the text labels.

The value of "TerminalInfoInteger(TERMINAL_SCREEN_DPI)" is 192.

Do you know how to solve it? I thought the libraries will adjust automatically according of my screen settings.

[Stanislav Korotky]

Guilherme Mendonca #:

Hi, 

I'm facing this kind of situation in one of my laptops.

Everything looks tiny except the text labels.

The value of "TerminalInfoInteger(TERMINAL_SCREEN_DPI)" is 192.

Do you know how to solve it? I thought the libraries will adjust automatically according of my screen settings.

Unfortunately I have no means to test it under different environments. The library is based on standard controls (with small fixes not related to dpi). So if it's screwed up somehow, this seems to be a common problem, not of the library.

But I think you should first check your Windows scale setting.

[Stanislav Korotky]

Guilherme Mendonca #:

I'm facing this kind of situation in one of my laptops.

Just an idea - try to patch Defines.mqh to:

#define CONTROLS_FONT_SIZE                  (-10)

The minus sign is added.

Or another idea:

#define CONTROLS_FONT_SIZE                  ((int)(10.0 / (TerminalInfoInteger(TERMINAL_SCREEN_DPI) / 96.0)))

Let me know if either variant helps.