Gallery of UIs written in MQL - page 71

[Реter Konow]

Edgar Akhmadeev #:

... I wrote the code according to the available information and got a beautiful interface. Then I ran into unrealised what I need personally. ....

By the way, what didn't work then, already works, because there is a software control of the interface. I remember then we could not output parameters to your tables. Now it is easy to do it. Your table can work and output values. It is already implemented in the engine. That's just for the record.

[Edgar Akhmadeev]

Not only do I know what's needed, but I've done the mockup. Here is your corrected code and layout https://www.mql5.com/ru/forum/467909/page37#comment_53863397.

I need exactly (in your terms) dynamic and generated tables. I.e. programmatically add an indefinite number of rows (well, limited by common sense), fill them, conveniently scroll the table itself, not the frame with it. So that the headings stay in place.

This is what you have in the works so far. That's why I'm quietly sitting on my arse and waiting. I'm in no hurry myself, and I'm in no hurry for you. I'm going to live forever. It's working so far.

[Реter Konow]

Edgar Akhmadeev #:

Not only do I know what's needed, but I've done the mockup. Here is your corrected code and layout https://www.mql5.com/ru/forum/467909/page37#comment_53863397

I need exactly (in your terms) dynamic and generated tables. I.e. programmatically add an indefinite number of rows (well, limited by common sense), fill them, conveniently scroll the table itself, not the frame with it. To keep the headings in place.

This is what you have in the works so far. That's why I'm quietly sitting on my arse and waiting. I'm in no hurry myself, and I'm in no hurry for you. I'm going to live forever. It's working so far.

I see. Well, dynamic and generated tables are necessary for me and you, so they will be. I will try to finish all the tasks before the New Year.

[hini]

How far along are we?

[Реter Konow]

hini #:
How far have we come?

Today, the concept of dynamic and generated tables is being formed, which are supposed to work in unison with scientific graphs. The task is not only to develop the technical part - tables and graphs - but also to find ways of "symbiosis" of these tools in analytical work.

Here is an example:

1. Data are uploaded to a file. Special algorithms distribute them into tables, rows and columns.

2. The user accesses the required table, selects a row and double-clicks to draw a curve or diagram using the figures from that row or column.

3. The user selects the required cell of the table and calls the construction of a new table by the data associated with the parameter located in it.

4. The user moves from tables to charts, from charts to tables and pie charts, "on the fly" assembling or generating new tables and charts. By simple clicks and entering parameters into the window, he can view data from different "angles" and in different combinations within the appearing graphical representations.

All this undoubtedly contributes to productive work and search for relationships and patterns in the data.

I plan to implement a convenient system of dynamic work with data through tables, graphs and charts.

The most important thing is the right concept. It takes the longest time to form. Technical implementation takes relatively little time.

P.S. Also, I am preparing my first article on GUI builder and markup language.

P.S.S. By the time the article is released, I will prepare a version for the codebase so that those who wish can download the constructor.

In general, there is a lot of work).

[Реter Konow]

I'll tell you what my plans are.

1. Create a textbook on markup language.

It is necessary to collect a complete textbook on markup language, organising it into parts, chapters and topics.

2. Write articles on interface builder and KIB language.

Divide the finished learning material into a series of articles, adding codes, diagrams, pictures and gifs to them.

3. Before publishing the first article, open a specialised thread with the sole purpose of publishing KIB code templates. Those who wish will be able to easily build a GUI by borrowing ready-made parts. They will also be able to add KIB codes if they wish.

4. Before the first article is released, post the latest version of the builder to the codebase.

On that page publish a detailed instruction manual with pictures, gifs and videos.

5. At the beginning of the article give a link to the builder and the installation instructions, and at the end of the article leave a link to the branch with templates. Thus, immediately after reading the article, readers will be able to try to create a graphical interface, borrowing ready-made windows or groups of elements. Then, as they learn, they will experiment and improve their interfaces.

6. In my opinion, in order to provide readers with easy understanding and quick mastering of the capabilities of the designer, it is necessary to simplify the presentation of the material and abundantly provide articles with informative pictures, readable schemes and commented codes. That's why I will write articles with the motto "the simpler the better", striving for logical simplicity and clarity of meaning.

7. Before publishing the constructor in the codebase, I need to do some preliminary work:

a) Translate the names of the catologues into English.

b) Completely remove all warnings that appear when compiling the constructor (not KIB-code).

c) Fix some previously noticed bugs in the work of controls.

d) Put a "stub" for debugging user code connected to the engine.

According to the idea, the engine will be switched off during debugging by simply commenting its line, and only the graphical core and wrapper functions from the "UIDATA.mqh" service file will remain connected. All other regular functions of the constructor will be set as "empty functions" serving as "stoppers" in a special file. The line of this file will be uncommented by the user before debugging.

This is the concept, but I haven't checked it in practice yet.

8. The first article will be the most difficult for me, because it will require me to briefly describe the whole constructor and markup language, giving readers a complete idea of their purpose, capabilities and device. Also, I will list the content of future articles and add a clear scheme of future distribution of educational material.

In my opinion, articles are lessons and therefore, the presentation of material should be pedagogical.

P.S. Initially I decided to rely on the example of well-known articles on graphical interface by Anatoly Kozharsky - Easy and Fast library. For me it is the most complete result revealing this topic. At the same time I respectfully acknowledge the contribution of other talented authors who made worthy attempts to create UI-libraries before and after Anatoly's articles. I would like to specially mention Dmitry Fedoseev and Artem Trishkin.

And so, having accepted Anatoly's articles as a standard of quality and an indicator of professionalism, I "tried on" their format to my own material and was forced to recognise the incompatibility. The differences in approaches and realisations are too great. Therefore, I will have to find and polish my style, not forgetting to meet the high authorial standard set by my predecessors.

[Реter Konow]

The process of working in the visual GUI editor on MT5.

4 years ago:

(Click on the picture).

P.S. The context of the demonstration is outlined in the post below.

[Реter Konow]

Time goes by and the idea of a visual editor continues to live in my mind. It doesn't want to leave me. And when I think about it at my leisure, every time I ask myself the question "what's the problem? - I've already created it, it's just not switched on."

In the prolongation of reflection I come back to the same conclusions: the basic functions of the visual editor are already present in my implementation, and only complex tools are missing. However, complex things can be created through the markup language, which in practice is much faster and more convenient than in visual mode.

As an example, tables and tree lists - it is long and painful to compose them manually, but it is easy and fast to write them in kib code.... especially when using templates. So why bother to invent cumbersome visual editing tools for tables and lists when you can build them with simple copy-paste? There's no point, that's pretty clear. But then what is the problem?

It's simple. The task is to combine the work of the markup language and the current capabilities of the visual editor. It is not necessary to add anything new to either the former or the latter - they only need to be combined in such a way that they complement each other.

Having seriously thought over this issue I came to the conclusion that even if now there is an opportunity to completely switch to visual GUI construction, I would refuse. The reason is that I don't want to lose the opportunity to use kib-code templates and simple copy-paste of elements or properties in the markup language environment. It's too valuable an advantage. Perhaps, not only for me, but for all future users who will be able to share their developments or simply copy parts of their previous developments. It's an indispensable thing.

That is, it is absolutely impossible to give up a markup language for the sake of a visual editor. I didn't understand it before....

And so, today the problem is to develop a system of harmonious combination of language and visual editor capabilities. And actually, technically, it's quite easy to do. (1) Firstly, all the necessary functions of the visual editor were written and tested several years ago, (2) and secondly, in recent months, the key mechanisms of the markup language have been well tightened up and a major upgrade has been carried out with the addition of software interface management. In other words, everything is ready for integration and merging, and the task is only to think through the concept of conflict-free interaction of both functionalities in the process of modelling and building a graphical interface.

Conceptually, markup language and visual editor ACTUALLY conflict.

There are several reasons that make this task difficult:

Recall that GUI elements and windows are written in code as standard, but can also be created in a visual editor, as shown in the gif above.

1) Both in the first and in the second case the functionality of the constructor builds the graphical core, although in different ways, but since the capabilities of the visual editor are weaker than those of the language, the created elements do not accept a full set of settings from the user through the editor. Settings can be supplemented by writing an editor, but then the markup language becomes unnecessary, and this is bad, because there is no possibility to rely on code templates. You can't give up the markup language, full stop.

2) When creating new elements and windows in visual mode, the markup language does not "see" them. That is, the markup language is not updated during visual construction of the GUI. Nothing is "added" to the original kib-code. This fact again leads to the conceptual separation of the visual editor and markup language. It is a conflict.

So, how to be and what to do in this situation? What is the compromise leading to the symbiosis of two powerful GUI building tools?

I'll try to understand the solution:

Main point: limit the role of the visual editor in modelling the interface, leaving the language features unchanged. Practically, this means:

1. Refuse to create new elements and windows in visual mode, because the markup code is not updated when adding them.

2. Leave the possibility of editing positions and setting properties of elements and windows of the user GUI through the settings windows of the visual editor, on top of default and custom values of the user in the kib code. In this case, the editor will write and save a special file with overrides of values, from which it will load them into the kernel and assign them to elements. In fact, this means a new type of element templates "processed" in the editor. They will not conflict with kib-code templates, only override the property values set in them.

This, in my opinion, is an effective symbiosis between editor and markup language.

P.S. The irony is that technically it is possible to realise the idea of merging editor and language capabilities in a few days, and it is quite realistic, but to think through all the details of their integration and interaction in the user's work.... that takes more time. :)

P.S. But the main conclusion is that they CAN and should work together, complementing each other.

[hini]

What you want to do is going to take a very long time, and your source code almost nobody will be able to contribute to the development, you'll have to rely on yourself.

[Реter Konow]

hini #:
What you want to do is going to take a very long time, and your source code almost no one will be able to contribute, you'll have to rely on yourself.

I strongly disagree with the first statement. The concept of a visual editor was not only thought out 4 years ago, but is technically implemented sufficiently to allow the user to easily assemble a simple settings window from basic controls. In the designer, for example, there is informative markup with dimensions and grid, there is a panel for setting properties and functions for saving a project and printing an API file, the same auxiliary windows with frames, images and fonts. Everything is just like in a markup language.

However: to complete the visual editor, a file navigator is a must. It will provide the ability to select folders for uploading or saving projects, and the good news is that the file navigator is already there - I showed it earlier on the branch pages - and even though it needs tweaking, but the basic functionality works.

In addition to the file navigator, we need to develop the concept of templates similar to kib-code. At first I thought it was impossible, but the solution turned out to be extremely simple: if there is a file navigator, the visual editor will be able to save the built interface not as a project, but as a template. After all, in essence, it is the same thing. Moreover, not only the whole project, but also separate windows of this project will be saved as a template. This is easy to do, because only a part of the built core is saved and it can be loaded into another project and the user will be able to extract (by copying shown in the gif above) the necessary elements and then erase this template from his project. I have the function of erasing windows and elements. That's it.

Tables can be built by simply copying cells according to the example from the buttons in the gif above. Same thing. The tree list is more complicated.... but it's not the main thing.

With a lot of enthusiasm, everything can be done in a month, month and a half. But now I am busy preparing material for articles, so this work is postponed.

As for the statement that other programmers won't be able to develop the project..... yes, they can't develop the project directly. But they can offer solutions, share their experience, opinions, offer functions of working with colour, with gradient. I am open to such interaction and co-operation.