Gallery of UIs written in MQL - page 24

New comment
 
Theoretically you could write (int) or (double) before each numeric value, but I leave that up to the user.
 
We have to "step on the compiler's throat", but in the end we win). It's not a big deal.


For the record. I respect programming rules and compiler's warnings, but in this case I have not found a better solution. I realise that some people may not like this approach, but it turned out to be the most optimal. And harmless.
 
I really hope that tomorrow will be able to post an update and those who want to finally start creating their own interface. I'll try my best.
 
Реter Konow compiler warnings, but in this case I could not find a better solution. I realise that some may not like this approach, but it turned out to be the most optimal. And harmless.
A small story:

When the question arose where to write the markup code, I faced two main options - in string array or in a file. Having weighed the pros and cons that came to mind, I decided that an array is much better for a number of reasons. First, instant initialisation and processing of the array contents by the constructor code. Secondly, lightning-fast access to individual attributes and properties of controls from the constructor/engine for reading/overwriting if necessary (with a file it would be a huge problem). And thirdly, it is much easier to send an array to a resource via a custom OnChartEvent() event. That's why we chose an array. And warnings... well, what can you do. You always have to sacrifice something to achieve the goal.

 
Correction to the text above: forward not by resource, but by slices of composed strings.
 
Well, and the total reason that will put the final nail in the "coffin lid" of the idea that markup could be written in a text file:

A .txt file can't be compiled to make sure there are no gross typos. This means that if the user messes up something badly with commas, quotation marks, spaces, etc., he will NOT KNOW IT FROM THE COMPILATOR.

Only after failing to build the interface he will have to realise that he typed the code badly and go inside to search and find every last typo. If it misses even one, the procedure has to be done again.

This is an insanely expensive price for the absence of compiler warnings.

That's why in MQL, the variant with string array for markup code has no alternatives and cannot be used. And compiler warn ings should be taken as a given.
 
P.S. The compiler warns even when a keyword is misspelled. Sometimes intellisense helps. In a .txt file, if you misspell keywords, you won't know. So there is no practical advantage of a file over an array.

I hope I have explained in detail why you should not get rid of compiler warnings in this particular case.

Good day, everyone.

 
Реter Konow compiler warnings should not be removed in this particular case.

Hello everyone.

Okay, understood.
 
Is this part of the code at the heart of the constructor
 
hini #:
Is this part of the code the basis of the constructor

The functions in this file link interface controls in various ways. For example:

1. The SWITCH_ALL command in the markup language means to set the activated state switching between all elements in a group. Suppose there are 10 radio buttons in a group. This command will make the buttons switch between themselves when clicked without additional code. The same is true for any elements - tabs, simple buttons, checkboxes, ... anything that can be clicked. Even different types of elements can be switched. The command is convenient if there are a lot of elements. If you need to switch individual elements within a group, their names are listed between the words SWITCH, ... END,.

2. The SYNC command works in a similar way, but with element parameters. It synchronises changes in parameter values. For example, we link the slider and the input field with buttons, so that when you enter a value in the input field, the slider moves to the desired position itself. Or by moving the slider handle, the values in the input field bound to it would change. You can synchronise the values of parameters of different elements if they have them. The "Set_SYNC()" function helps to do it.

3. C.word BLOCKS opens the list of elements to be locked when the main element is pressed. The "Set_lock_elements()" function is partially responsible for this command.

4. The function "Set_link_between_fields_and_tabs()" does exactly what its name says - it establishes a link between clicking on a tab and opening the space of its elements inside the window. That is, it manages the phenomenon of the elements assigned to it.


Can this be considered the basis of the constructor? Rather, it is one of the parts, of which there are many. The basis of the constructor is scattered over many files and is not collected in one place for objective reasons.


P.S. By the way, at first I wanted to release the constructor in one file and collected it. It turned out to be ~37 thousand lines. But even in that file I couldn't point to the basis of the constructor, because it can't be collected in one place for technical reasons.


I hope I helped in understanding, now I'll go to work on the release.))) If there will be questions ask, I will try to answer as much as possible).)

1...171819202122232425262728293031...63
New comment