Gallery of UIs written in MQL - page 65
You are missing trading opportunities:
- Free trading apps
- Over 8,000 signals for copying
- Economic news for exploring financial markets
Registration
Log in
You agree to website policy and terms of use
If you do not have an account, please register
How to get the on/off state of the button?
This is the next topic. We will consider it today.
I should add that the elements of this GUI are drawn, so the standard method of getting the state ObjectGetInteger(0, "button1", OBJPROP_STATE); will not work.
Also, let me remind you that events of elements, including buttons, are sent to the API file.
A general list of topics to consider:
1. Orientation in the list of intellisense and selecting the function of the right window.
2. Programmatically opening and closing windows.
3. Orienting in the list of intellisense and selecting the right element in the right window.
4. navigating through lists of individual element properties.
5. Parsing the name of an element and window wrapper function.
6. returning the parameter value of a selected element to a variable of its type. Consider three types of several different elements.
7. Setting values in the parameters of different types of elements. Let's see how the values will appear in the interface windows of these elements.
8. Returning the parameter values of one element, modifying and forwarding that value to another element. Consider different types of elements and values, and test forwarding between different types of elements in different windows.
9. Return previous value (_V_LAST). When and for what cases the last value is required (not to be confused with the current value).
10. Test the setting of ON/OFF/LOCK_ON/LOCK_OFF/LOCK/UNLOCK states for different types of elements.
11. Let's try to link and synchronise changes of values of elements of different types: for example, input field with buttons and slider. Let's assume that when the value of one element (manual or software) changes, the value in the second element changes accordingly.
12. Let's try to programmatically reset the range boundaries of the slider and the input field with buttons via wrapper functions. I haven't had time to test it, but something suggests that it will work. However, let's see.
13. Let's try to return element states through wrapper functions. It is included in the functionality, but I haven't had time to test it. So we'll see... The result is unknown.
14. Let's get and set colours for text and element bases. We can try to associate these colours with some simple events or value boundaries.
15. I'll tell you more about how to navigate and read the new API file printout.
//------------------------------------------
The topics we have already covered are highlighted in yellow.
Today we will review:
11. Synchronisation (linking) of changing values of elements of different types: for example input field with buttons and slider. So that when changing the value of one element (manual or software), the value in the second element will change accordingly.
12. Let's try to programmatically reset the range boundaries of the slider and the input field with buttons via wrapper functions. I haven't had time to test it, but something suggests that it will work. However, let's see.
13. Let's try to return element states through wrapper functions. It is included in the functionality, but I haven't had time to test it. So we'll see... The result is unknown.
11. Binding of parameters of elements of different types.
The observant person has noticed that in a multi-window GUI, different elements are often linked by parameter values, properties, and states. For example:
//-------------------------------------------------------------------------------------------------------------------------
//-------------------------------------------------------------------------------------------------------------------------
You'd think there's an invisible element connection going on somewhere. And there really is. But it is invisible only for an outside observer. For a developer it is quite obvious and today we will consider it in detail.
1. The connection of elements has two sides:
Technical realisation of connections is simplified due to the presence of a graphical engine.
Let me explain:
In a conventional Expert Advisor, each parameter is invented, named, stored and processed by theuser. This is a routine work that cannot be bypassed. However, in case of using a graphical engine, the items created in the constructor automatically receive the parameter along with the storage location and processing/return function. In addition, the user gets their properties like type, range, past value, etc. This greatly simplifies the labour. Theoretically, it is possible to use ready-made parameters of GUI elements as other user parameters, linking them directly to the trading logic. For example, lot, trailing stop, take take profit and others, not from their own variables, but from the settings fields responsible for their values.
Some general conclusions:
1. The presence of a graphical control in a programme = the presence of a ready-made programme parameter + its properties + the function of returning/setting the value.
2. The more controls are placed in the windows of the interface programme, the more parameters are involved in trading logic and input/output of trading information.
3. The more settings and windows - the higher the control and wider the bandwidth of market data output (without prejudice to automation).
4. The higher the control and wider the bandwidth of market data output - the better the trader's awareness.
5. Awareness multiplied by automation and control = scaling of trader opportunities.
I should add that automation is often opposed to manual control. They say that having a graphical interface means manual trading. But it is not so. The software interface does not exclude but expands automation, adding a "gradient" to it - it opens three options: manual control, semi-automatic trading and autonomous mode.
All a trader needs to do is to select an option.
Goodness, it is easy to create a window for this purpose.
//---------------------------------------------------------------------------------------------------
2. Let's move on to the technical implementation of binding parameters of controls.
Let's consider some practical examples:
1. Let's open a familiar settings window:
2. Open the API file and find the elements of the opened window inside the On_Gui_Event() function:
Reminder: All control events come into the On_Gui_Event() function;
In this regard, we will write some of the parameter links inside this function, and some outside its body.
1. Let's establish a connection between the field with buttons (S_EDIT) "Spin the value" and the slider (H_SLIDER) "Roll the value":
Result: we change the value in the field with buttons, and the slider moves by itself.
(*Important - the slider can move only within its range (in this case, from 0 to 100). In case of exceeding the range, the value does not change, but an error is displayed in the log).
//----------------------------------------------------------------------------------------------------------------
3. Let's do role reversal. The slider will control the value in the input field:
Result: When moving the slider handle, the field with buttons changes the value synchronously.
//----------------------------------------------------------------------------------------------------------------
4. Let's write the mutual control of the slider and the field with buttons by each other:
Result: Slider and input fields control each other simultaneously.
//---------------------------------------------------------------------------------------------------
Tomorrow I will post the second part of this theme with other elements.
This stuff is awesome! I plan to check out this thread in more detail given time. I thought my work was pushing the envelope of mt4 GUI but your work is next level.
This is some awesome material! I plan to explore this topic in more detail when I have time. I thought my work was pushing the boundaries of mt4 GUI, but your work is next level.
Thank you very much for your kind words!
11. Binding parameters of elements of different types.
Continuation of the topic.
Part 2.
//--------------------------------------------------------------------------------------------------------------------------------
Let's see if we can apply the shown binding method to other elements. For example, to checkboxes.
1. Let's make the top checkbox lock and unlock the checkbox below it:
To do this:
1. Let's find the"Set an option" checkbox in the API file.
2. Write a function call for the"Set another option" checkbox that should lock/unlock.
Result: the checkbox is locked and unlocked as intended:
//--------------------------------------------------------------------------------------------------------------------------------
2. Now, let's make the checkbox lock and unlock the two checkboxes below it:
Result: the checkbox locks and unlocks the two checkboxes below it:
This is how it happened in dynamics:
//--------------------------------------------------------------------------------------------------------------------------------
3. Now let's solve the problem shown in the diagram below: the checkboxes should lock and unlock the drop-down lists opposite them.
To do this:
Result: the checkboxes lock the dropdown lists, and lock themselves with the main checkbox:
//--------------------------------------------------------------------------------------------------------------------------------
4. Let's move on to the next task: the drop-down lists should translate the value selected by the user into a field of another window.
To do this:
*Result: both dropdown lists successfully send their values to the input fields in the opposite window:
//--------------------------------------------------------------------------------------------------------------------------------
5. The following task is shown in this diagram: You need the radio buttons that are switched to send their name to the input fields opposite.
To do this:
*Importantnote: radio buttons are toggled because the SWITCH operator was applied to them in the KIB code. Therefore, they have one common parameter for all of them and are in the API file in the same case.
Result: Switching the buttons causes the text in the input field to change. *There is a small technical problem with this option. Itwill be fixed in the next version.
The second part is completed.
In the third part we will work with the table.
The final part of the topic of parameter binding.
Let's pass the values of the element parameters to the table cells.
Schema:
Solution:
Result: the values are safely placed in the selected table cells.
As you can see from the above examples, we have developed a simple and convenient solution. I hope people will find it useful.
This concludes the topic of linking element parameters.