Gallery of UIs written in MQL - page 78

 
Реter Konow #:
It's not an easy thing to do. )

As far as I know, there is no functionality in the standard Ccanvas class to draw a colour gradient, how did you solve the problem with a gradient in your GUI?
It's all solved by formulas in the code
Files:
 
Yu Zhang #:
friend, If you can figure out how to use the GUI when backtesting your EA, I would be grateful.

Nothing easier than that. 

The described core manages ALL events, it does not matter if the event is a tick or a chart-event. You can simply get mouse position etc. also in a tick, check for changes and then fire the OnEACylce() for chart-event. You are no longer restricted to anything. 

 
Tomorrow I will post a detailed update of the development status.

Today I can say that two of the 6 editor foundations have been laid.
 

Current development status:

1. A lot of work has been done to integrate hundreds of properties of objects, elements, windows and parameters into tabs and tables in the editor. It was necessary to separate and sort them. Approximately 70% of this task has been completed. Not all of these properties will be needed by users in their work, but I need them for further development of the editor.

2- The scrolling mechanism has been debugged. Now each tab "remembers" the position of the slider and when you return the canvas is automatically scrolled to the last place of viewing.

3. Fixed lags related to scrolling. For example, while scrolling with the mouse wheel, interactive elements do not react to the cursor at the specified speed threshold. If the arrival rate of wheel events is more than 3 per second (300 ms between events), elements falling under the cursor are not redrawn. Also, now only the strip space and its components are drawn during scrolling. The rest of the canvas space is not ignored.

4. The work of T_FOLDER elements - table collapsers - has been adjusted. It can be clearly seen on the video.

5. Found and fixed problems with the phenomenon of elements.

6. The design of the editor's subwindow is better thought out. Convenient and aesthetic solutions have been found. However, there is a lot of work to be done in this direction.


The nearest plans:

1. Write functions Get_property() and Set_property(). They will allow to edit instances copied from templates. The first function will get all properties (more than 300) from each element at once and put them in the editing elements in the editor tabs (those in the video). The second function will send custom values from the editor element to the editable instance property on the main canvas (in the centre).

2. Restore the manual element editing functionality that worked well 4 years ago.


 
Today is the 21st of December. I expected that the minimal version of the editor would be ready in the tenths of December, that is, before the 20th, and in principle it would have turned out that way if I had restored the previous minimal version that worked before, but I decided to create a full version of the editor. That's why there was a lot more work than expected.

Earlier I talked about the 6 basics of a visual editor. Let me remind them:

1. Cloning elements/windows.

Creating new instances of elements by copying templates and modifying their properties.

2. Deleting elements/windows.

Erasing previously cloned instances from the core.


3. Retrieving properties of windows/elements.

Property editor elements should retrieve property values of instances that fall into the edit focus.

4. Editing properties of elements/windows.

There are 2 ways to edit properties in total: (1) via element editors and (2) manual editing of instances. For example rippling, moving, printing on x surface, etc.


5. Loading templates/projects.

Functionality allowing to load saved templates and projects inside the editor for further editing.

6. Saving templates/projects.

Functionality that saves finished GUI templates and projects in files for later transfer to custom programmes or for use as beta versions and re-loading for editing or copying parts.

In general, these are the six basics of a visual editor.

As a seventh foundation, I would add a graphical editor interface without which it cannot function.


Before the New Year, I expect to implement cloning, deletion and visual editing both with element-editors and in manual mode. We'll see what I can do in time.


 
6 basics (short and clear)

1. Copying elements.

2. Deleting elements.

3. Manual editing (moving, stretching, printing).

4. Editing via controllers (getting properties into element-editors and changing them).

5. Loading GUI templates and projects from files.

6. Saving templates and GUI projects in files.
 

Need a good instruction, video tutorials on how to create a panel from A to Z. Interface in Russian ;)

Otherwise the abundance of functionality is frightening.

 
Aleksey Vyazmikin create a panel from A to Z. Interface in Russian ;)

Otherwise the abundance of functionality is frightening.

Yes, I expect to make video tutorials and write a couple of articles. But perhaps the main task is to make the editor self-explanatory. For example, when moving the cursor over an element, arrows will appear, it will be clear to the user that he can grab it by its edges and change its size. And if a crosshair appears, he will realise that the element is dragged on the canvas. When clicking on an element, its dimensions will be drawn - height and width - also quite clear. Text and icon can be moved inside the element. When pointing at them, arrows will also appear. Text size can be changed by stretching. The distances between elements when moving, as well as the coincidence of their positions vertically and horizontally also appear on the canvas in the form of red lines. In this respect, everything is clear at once.

As for editing elements, I'll put the ones responsible for the main properties on the top, and move the rest down. In addition, it will automatically lock those elements that do not belong to the instance being edited at that moment. This will simplify the work in the window of element-editors.

Further, hover tooltips will appear above obscure property names. They will explain to the user the meaning of this or that property of the element being edited. At this stage, everything is clear.

As for the editing canvas in the centre. While the final concept has not yet formed. I assume that the user will collect there the templates of elements or groups and transfer them to the windows. That is, from the left subwindow of templates he will copy the element by drag and drop, change the size, colour, text and so on, then clone several such things and save them in a file as a template or immediately transfer them to his window. I think one short video will be enough to explain this process to users.

By and large, almost nothing in this editor will require long explanations or tutorials and its mastering will take no more than an hour. And this is its undeniable advantage over markup language).


 
Реter Konow #:
By and large, almost nothing in this editor will require long explanations or tutorials and its mastering will take no more than an hour. And that's its undeniable advantage over markup language)
.

Good goal! It is necessary to recruit testers who will really master the functionality from scratch, then it will be more obvious what to pay attention to in the ergonomics of the interface....

 
Aleksey Vyazmikin #:

Good goal! It is necessary to recruit testers who will really learn the functionality from scratch, then it will be more obvious what to pay attention to in the ergonomics of the interface.

I agree, but we need to get there. One person has already volunteered to be a beta tester on the pages of the branch, I hope there will be others, but it's too early. Sometime in the next month the initial testing of the editor will become relevant. There is still a lot of routine work that slows things down considerably. All those property tables, template groups, tab and group assignments, design decisions, minor bugs... but, nobody said it would be easy).