Discussion of article "MQL as a Markup Tool for the Graphical Interface of MQL Programs. Part 1"

[MetaQuotes]

New article MQL as a Markup Tool for the Graphical Interface of MQL Programs. Part 1 has been published:

This paper proposes a new conception to describe the window interface of MQL programs, using the structures of MQL. Special classes transform the viewable MQL markup into the GUI elements and allow manage them, set up their properties, and process the events in a unified manner. It also provides some examples of using the markup for the dialogs and elements of a standard library.

Why is layout separated from code and described in a special language? Here are the basic benefits of such approach.

• Visual presentation of hierarchic relations among elements and containers;
• Logical grouping;
• Unified definition of layout and alignment;
• Easily writing the properties and their values;
• Declarations allow implementing the automatic generation of the code maintaining the lifecycle and control of elements, such as creating, setting up, interactiing, and deleting;
• Generalized abstraction level, i.e., general properties, states, and initialization/processing phases, which allows developing the GUI independently on coding;
• Repeated (multiple) uses of layouts, i.e., the same fragment can be included in different dialogs several times;
• Dynamic content implementation/generation on-the-fly, in a manner similar to switching among tabs, a specific set of elements being used for each of them;
• Dynamic creation of "controls" inside the layout, saving them in a single array of pointers to the basic class, such as CWnd, in case of the standard MQL library; and
• Using a specific graphic editor for the interactive interface design — in this case, the special format of describing the layouts acts as a connecting link between the external representation of the program and its executive part in the programming language.

For the MQL environment, just a few shots have been made at solving some of these problems. Particularly, a visual dialog designer is presented in the article How to Design and Construct Object Classes. It works based on the MasterWindows library. However, the ways of arranging layouts and the list of element types supported are considerably limited in it.

A more advanced layout system, although without a visual designer, is proposed in the articles Using Layouts and Containers for GUI Controls: The CBox Class and The CGrid Class. It supports all standard control elements and other ones, inherited from CWndObj or CWndContainer, but still leaves the routine coding aimed at creating and arranging components to the user.

Conceptually, this approach with containers is very advanced (if suffices to mention its popularity in practically all markup languages). Therefore, we are going to take heed of it. In one of my earlier articles (Applying OLAP in Trading (Part 2): Visualizing the Interactive Multidimensional Data Analysis Results), I proposed a modification of containers CBox and CGrid, as well as some control elements to support the "rubber" properties. Below, we're going to use those developments and improve them to solve the problem of automatically arranging elements, exemplified by the objects of a standard library.

Author: Stanislav Korotky

[Реter Konow]

Very, very cleverly written. But, at the same time, it is immediately clear that the author is at the very beginning of his journey and does not yet know the basics of technology.

For example, the fact that nesting and hierarchy of elements is actually absent. A window element is not a hierarchy. And base-text-icon? - Do they have a lot of common properties? There are, but it is inefficient to create an "ugly" bundle of several different classes with inheritance of few coinciding properties.

Inheritance is almost irrelevant in the concept, and rather "overkill", because there is no depth and variety of objects. They are parallel rather than nested.

As for elements: yes, the variety of them is great, but again there is no reason for inheritance. They are all different and it is unnecessary to mould them into a "lump".

And I wouldn't advise to get too stuck on small things like variable names, because you won't have enough life to complete such a project alone. A too professional approach will stall for years. You need to be amateurish and then, perhaps, you will be able to reach the vis.editor.

[Реter Konow]

I read the article carefully again and did not find the concept of markup language. There are some thoughts about implementations in other languages and possibilities to borrow some libraries, but the author has not built the concept yet. Without it, it makes no sense to borrow or modify anything.

The concept should be described in simple and clear words, without codes, and explain the essence of the technology - what and how it should work. But in the article there are some codes, examples, etc.... What are they about?

The chapter:"Designing a markup language" does not contain the concept of a markup language. Author, pay attention that you didn't write anything about markup language technology, but went straight into some details, how, where and what can be borrowed. Then, you talk about some hierarchy of controllers (which you don't actually describe) and go into unrelated specifics.

It is necessary to start with the concept of the technology being created, and there is no such concept yet.

[Maxim Kuznetsov]

Good article and good decisions, nice to read.

To make it 5+, a little bit was not enough - a brief review of "what is bad/good in the rest of the world" :-) The author clearly owns it and writes not from nothing ...

I expect from the following parts: something like Geometry & Style Managers (this is to get rid of the calculation of coordinates and distribution of colours), the work of GUI in terms of interaction with the basic logic.

[Dmitry Fedoseev]

another gasket.

How many pieces will it be, 38 or 55?

[Igor Makanu]

Dmitry Fedoseev:

And how many parts will there be, 38 or 55?

not everyone can write "War and Peace" in articles on the MQL forum.

The author of more than a cycle of 4 articles has not been seen before ))))

The material of the article seems to be well read, but there is some discomfort, somewhere I do not know what to base it on - XAML is taken as a basis? - unfortunately, I have not studied it and do not use it, as well as except WinForms and do not use other features of C#.

In general, interesting, let's see what's next, the only wish is a little more pictures, in my opinion the material looks very dry if you just read it.

[Реter Konow]

The author's professionalism inspires hope, provided that he can handle the concept and implementation from start to finish. The first article hints at the intention to take a ready-made library, modify it and turn it into a markup language. I don't believe in the sense of such a solution. The library itself is limited, and the markup language will be weak. Without a qualitatively new level of technology and controllers on the canvas - "sheepskin" is not worth it, and if the author takes up the drawn elements - you need to redo the basics. All this requires a very deep understanding of technology and a lot of time. Judging by the way the author clings to the names of variables (which will be thousands), syntax, rules - I'm afraid, will not reach completion....

BUT! This is only the first article. Let's see...

[Dmitry Fedoseev]

Igor Makanu:

not everyone can write "War and Peace" in the MQL forum in articles

the author of more than a cycle of 4 articles has not been seen before ))))

The material of the article seems to be well read, but there is some discomfort, somewhere I do not know what to base it on - XAML is taken as a basis? - unfortunately, I have not studied it and do not use it, as well as except WinForms and do not use other features of C#

In general, interesting, let's see what's next, the only wish is a little more pictures, in my opinion the material looks very dry if you just read it.

I tried to study XAML, only from the very beginning, and I didn't understand the joke of humour - why to study one more language, and even extremely narrowly specialised, which, besides, doesn't expand the possibilities, but narrows them. Anyway, one day you will want to "tweak" something when the programme works or make the interface more flexible, so you will have to study how everything is done in a direct way without pads. The benefit of the markup language is insignificant, and if you take into account that you still have to learn it, it is very doubtful. Or I didn't understand the ideology of XAML.

[Igor Makanu]

Dmitry Fedoseev:

And I tried to study XAML, only from the very beginning, and I didn't understand the joke of humour - why study another language, and even a very narrowly specialised one, which, moreover, does not expand the possibilities, but narrows them. Anyway, one day you will want to "tweak" something when the programme works or make the interface more flexible, so you will have to study how everything is done in a direct way without pads. The benefit of the markup language is insignificant, and if you take into account that you still have to learn it, it is very doubtful. Or I didn't understand the ideology of XAML.

we will wait for the author of the article, may give the direction of search what is convenient XAML, maybe I will read, although the main thing, in fact - what will be the result of the article, how convenient and functional it will be, at this stage I am satisfied with SB for graphical primitives - the sources are available and readable.

SZY: about new languages, well, everything is relative, I wanted to use SB to save a couple of charts in .bmp... I didn't understand it in a day, I spit Googled, I got acquainted with Google Charts in 15 minutes and instead of .bmp I generate .html - even offline you can view charts, i.e. usability is the key to use! ;)

[Andrei Novichkov]

Dmitry Fedoseev:

And I tried to study XAML, only from the very beginning, and I didn't understand the joke of humour - why study another language, and even a very narrowly specialised one, which, moreover, does not expand the possibilities, but narrows them. Anyway, one day you will want to "tweak" something when the programme works or make the interface more flexible, so you will have to study how everything is done in a direct way without pads. The benefit of the markup language is insignificant, and if you take into account that you still have to learn it, it is very doubtful. Or I didn't understand the ideology of XAML.

The great value of XAML is that it simplifies the development of all kinds of dialogue windows and other nonsense. In MFC it's not easy to create a list with a different appearance from the standard one, you have to try hard, but here it's one or two times. I've been messing around with it, it's mind-blowing, but if you need to make interfaces, you can master it. And you don't need to learn it, it's just a piece of Sharp. It really starts to save time, not immediately, but as you learn it.

[Алексей Мокрушин]

People, why are you piling on a person from the first article when you can't see the result? I have never once written comments here, but yours made me do it.

I am not a professional programmer, but an amateur. And many articles here, even unsuccessful ones, make me look for better solutions, study programming languages more deeply. To understand why the author has implemented this particular way of solving the problem. To apply something in my own developments. Any article makes me increase the amount of knowledge many times more than if I just read books and documentation.

Here is a simple example. There are already a number of articles on GUI here, but everything is implemented, though with the help of classes, but in procedural style. It is cumbersome and inconvenient. You need to understand the whole code from the beginning to the end. It made me look at other languages, such as C++, C#, where by overriding a virtual method, for example doubleclick, you can implement what you want without getting into the wilds.

I started to study design patterns, dynamic data structures, as there are no delegates in mql, I had to understand what this dish is and what it is eaten with. I had to rewrite all the standard classes. I started from the beginning, with CObject. In the end I wrote a simple implementation of OnTradeTransaction, OnChartEvent, OnTimer event handling using "real" OOP. I'm not familiar with XAML markup, when I tried to study it seemed very tedious, but now I will get into it to understand what the author wants to convey, and had the opportunity to implement some of his ideas for myself.

So before you sharply criticise any article, think that there are people like me who need a different view on the same subject. Suggest, guide, if you have deeper knowledge. Team up. It will be more productive than shitting on an article.