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
Before continuing with the topic of implementing staggered parameter boundary protection and user warnings, we should mention another topic that directly precedes it. Namely, parameter presetting.
I will start with the well-known: most MQL programmes have variables of the input category. They are declared at the global level and are visible in a single settings window. The window appears at the start of the programme and inside it the user can change the initial values of "external" variables, if such a need arises. But before that, the user initialises the external variables inside the program. The point is that programme presets are not universal, and that's why there is a category of variables that require the possibility of setting at each startup. It is also known that any attempt to manually access external variables during programme execution is impossible and requires a reboot. With a graphical interface, this necessity is eliminated. The programme settings can be opened at runtime.
However, there is still the same necessity to set initial values to the programme parameters at the start.
If we have a graphical interface , there is no sense in declaring variables of the input type , because we no longer need the standard settings window , but the essence remains the same. Instead of input variables, we must set initial values to the parameters of controls.
At the initialisation of the program we should call some function that sets initial values to our own windows, not the standard window. As an option, this can be done in the KIB-constructor, at the stage of interface building, when V_CURRENT values are set, or ON/OFF states, etc., but now it is possible to initialise elements programmatically. Now it is possible to combine initialisation of elements in the constructor and in the program.
Therefore, we need a special function called from OnInit() to do this job.
What exactly this function will do:
What will the function be called?
I would call it Initialize(), but anyone can come up with their own variant.
Themain thing is that this function must be in any interface Expert Advisor. It can be compared to the OnTick() function of an Expert Advisor or OnCalculate() of an indicator. It is important to understand this.
What value will the function return?
The function will have the void type . There is no need to return a value. When called, it will open the necessary windows, initialise the parameters of elements, and possibly preset some properties. That's basically all. Theoretically, you can set initial parameter bounds in it, but I think that the value control will be implemented in a separate function called on element events from the API file and from the timer. I will probably write a printout of control calls in the next version.
*It is important totake into account that at the moment the concept of interface Expert Advisors is just being formed and many discoveries are ahead of us.
Here is an example of the initialising function of an interface Expert Advisor in the context of the current demo project:
1. Function call:
2. Function implementation:
So far, I see the structure of the function as follows. A very simple function. It opens windows and sends the required values to the element parameters. It is possible to change the initialisation of elements and opening of windows in places, because opening windows will immediately show the required values of elements without additional redrawing. However, these are minor things.
Then let's move on to the main topic: implementation of step-by-step protection of parameters.
14.realisation of step protection of parameter boundaries:
//------------------------------------------------------------------------------------------------------------
Writing the logic of controlling the settings within the preset limits, and creating a warning system:
//-----------------------------------------------------------------------------
Let's proceed:
1. Set the initial values of the parameters of the selected elements and open the necessary windows. To do this, let's write theInitialise() function and call it in the _OnInit() function.
Result: The required windows are opened and initial values are set to the target elements.
2. Open the API file and write the connection of elements. In the case of each element, write calls and passing the value to the other target elements in the chain:
3. Test the connection:
Result: element values are connected as intended.
4. Write a function to control the parameters of our group of elements: void Risk_management_group_1().
Call the Risk_management_group_1() function from the _OnInit() function:
Result: works as intended, but when entering a value in the input field, the warning window does not reset the entered value when it appears(requires improvement).
(*Also - setting the frame colour was added in the update, but is missing in the current version).
The next task is to consider cancelling the entered parameters by pressing the "Cancel" button.
This is a very difficult task, but I have already partially implemented it. I will try to restore the previous functionality.
In the last breakdown I showed how to apply colour indication of risk and open blocking windows at the crossing of set parameter limits. However, two problems that I did not expect were discovered.
1. The risk management function opens the first warning window when a dangerous level is crossed, but if you keep the cursor pressed on the element at that moment, the value continues to grow and reaches the next conditional level. - Critical.
2. When the critical value is crossed, the last warning window opens, but it does not stop the value from changing either if the user continues to hold the left mouse button.
3. If the user releases the mouse button and wants to close the warning windows, he cannot do it. To be more precise, he couldn't. The reason is that the two blocking windows start blocking each other. When one of the blocking windows is open, it is easily closed, but when two windows are open at the same time, nothing else in the interface can work. The programme goes into a stupor, although it still works.
The image below shows how this happened:
Then, I fixed the mutual locking problems of the settings windows and now the windows do not interfere with each other. They perform the locking function together without conflicting with each other.
Now I need to make it so that the warning window will automatically stop changes to the parameter value, even if the left mouse button is pressed and the item is active.
You can understand that.