![MQL5 - Language of trade strategies built-in the MetaTrader 5 client terminal](https://c.mql5.com/i/registerlandings/logo-2.png)
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
12. Programmatically obtaining/setting the value boundaries of the slider and the field with buttons (_V_MIN, _V_MAX, _V_STEP, _DIGITS).
1. Let's open a window with elements with the above parameters:
2. Let's write the values of _V_MIN, _V_MAX, _V_STEP, _DIGITS and output them to the log:
Result: the values of the slider parameter properties are logged.
//---------------------------------------------------------------------------------------------------------------------------------------
3. Let's repeat the operation with the field with buttons. Unlike the slider, the field has other number boundaries and its value type is double.
Result: thevalues of the parameter properties of the field with buttons are displayed in the log.
//---------------------------------------------------------------------------------------------------------------------------------------
4. Set other boundaries of the slider range (tested for the first time, the result is unknown).
Result: *found aproblem with the range in negative numbers (fix in the next version).
Let's check with positive range bounds:
Result: range bounds successfully changed.
Main point: The range of the slider can be changed using its function.
**Important:You cannot retroactively change the parameter value type from int to double or vice versa.
//-------------------------------------------------------------------------------------------------
Let's perform a similar experiment with the input field:
Result: It works as intended. The field with buttons accepts the specified range and step. If the range is exceeded, it reports an error to the log.
//--------------------------------------------------------------------------------------------------
5. Finally, let's set the value_DIGITS to the field with buttons (the slider won't work because its parameter type is int):
Result:
Results:
This concludes this topic.
13. Querying the state of elements _GET_STATE.
Often there are situations when it is necessary to programmatically get the state of one or another element of the interface. To solve this problem the identifier _GET_STATE is created.
//--------------------------------------------------------------------------------------------------------------------
*Important:On the request_GET_STATE, function returns the index of the current state of the element.
//--------------------------------------------------------------------------------------------------------------------
The image below shows the list of element states.
1. state identifiers :
(*in thenext release, the prefix v_ will be replaced by the prefix s_)
Indices output to the log:
Let's test querying and retrieving element states:
1. Open the window and get the initial state of the "Start" button:
Result: the value 15 corresponding to the state v_NEUTRAL_STATE is obtained .
2. Let's log the states of the button on press and release:
To do this:
Result: on the pressed/released event, the current state index is printed to the log.
Reminder:
//----------------------------------------------------------------------------------------------------------------
3. Let's repeat the query with the checkbox.
1. Let's get the state of the checkbox on the event of window opening:
Result: the value 15 is obtained, corresponding to the neutral state v_NEUTRAL_STATE (where the checkbox is).
2. Next, let's query the states of the checkbox on the press and release event.
To do this:
Result: we get values 66 (v_NEUTRAL_HIGHLIGHTED) and 67 (v_ACTIVATED_HIGHLIGHTED), which means highlighted neutral and highlighted pressed state.
//-----------------------------------------------------------------------------------------------
This concludes the first part of the topic.
In the second part, we will return the states of the D_LIST drop-down list, the H_SLIDER slider, and the S_EDIT and EDIT input fields.
13. Status request _GET_STATE.
Part 2: Getting the states of D_LIST, H_SLIDER, EDIT, S_EDIT elements .
In the last part, we looked at programmatically returning the states of the BUTTON button and CHECKBOX checkbox. The _GET_STATE query was used and the list of state names returned by the functions was shown. There are six names in all, where each begins with the prefix v_. (An abbreviation of value, which will be replaced by s_ - an abbreviation of state).
Recall the state indices:
In this case, the specific index numbers are not important. When the user needs to put a particular state into a condition, he uses an identifier.
Example 1:
Example 2:
//-----------------------------------------------------------------------------------------------------------------
*Very important:
Let me explain the essential difference between v_NEUTRAL_STATE and v_NEUTRAL_HIGHLIGHTED states , and between v_ACTIVATED_STATE and v_ACTIVATED_HIGHLIGHTED:
v_NEUTRAL_STATE - это нейтральное состояние в котором элемент находится неопределенное время. v_NEUTRAL_HIGHLIGHTED - это нейтральное состояние в которое элемент перешел ТОЛЬКО ЧТО, после отжатия пользователя. Поэтому элемент подсвечен - HIGHLIGHTED.
the same applies to the activated state:
v_ACTIVATED_STATE - это активированное состояние в котором элемент находится неопределенное время. v_ACTIVATED_HIGHLIGHTED - это активированное состояние в которое элемент перешел ТОЛЬКО ЧТО, после нажатия пользователя. Поэтому элемент подсвечен - HIGHLIGHTED.
This difference makes a big difference.
Currently, the button and some other elements, only return v_NEUTRAL_STATE and v_ACTIVATED_STATE, and do not return HIGHLIGHTED states like a checkbox. This means that the user has no way of knowing if items were clicked/unclicked just now, or when, an indefinite time ago. However, the user can catch the moment they were pressed in the API file. Yes, but this feature is not yet available in the rest of the programme. In the next version, HIGHLIGHTED state return will be added to all interactive elements. This way, from anywhere in the programme, the user will be able to know whether an element has just been pressed/unpressed, or has been in its state for a long time.
//----------------------------------------------------------------------------------------------------------
Let's move on to the practical part:
1. Open the windows:
2. Let's get the states of the elements:
Result: all elements of the D_LISTcnome have state index 15 (neutral state v_NEUTRAL_STATE). D_LIST returned an error (-1).
Reason: the return of states of this element is not specified in the central function. Technical defect.It will be corrected in the next version.
Since the D_LIST function does not return the state index yet , let's focus on three items whose states were successfully received: EDIT , S_EDIT and H_SLIDER.
What to check:
We have just verified that the EDIT, S_EDIT and H_SLIDER element functions return an index of the neutral state when the window is opened. It remains to check the other states. Since these types of elements, in theory, can only be in neutral, locked and highlighted states (unlike buttons and checkboxes, which have more states), we have to check the following two possible states: locked and highlighted. There is also a group of"under cursor" states, which I don't want to add yet to avoid confusion. In the next versions I will create a special prefix that opens an individual list of possible states of each type of element. This will make programmatic work easier.
How we will check the return of the blocked and highlighted statesEDIT, S_EDIT and H_SLIDER:
1. Find the "Set an option" checkbox in the API file and write the locking/unlocking ofEDIT, S_EDIT and H_SLIDER elementsinside its case.Then, output the states via Print().
Result:
//--------------------------------------------------------------------------------------------------
2. Second task:
Getting started:
Result:
//-----------------------------------------------------------------------------------------------------
Results:
In general, the results can be evaluated as satisfactory. Elements return indices of neutral and locked states as intended. However, there are some shortcomings:
Conclusions:
Potentially, it is possible to add new element states. For example, Neutral pointed and Activated pointed ( neutral under the cursor and activated under the cursor), but there is a question of practicality and the real need of the user to have these features. Until such requirements are not received, I will not add new states.
That's the end of this topic.
Further, to the following topics.
I've spent the last week researching how to write an interface using WinForm and embed it into MT5 charts. Today I finally realised it.
A general list of topics to consider:
1. Orientation in the list of intellisense and selecting the function of the right window.
2. Opening and closing windows programmatically.
3. Opening a list of programmatically available window elements.
4. Opening a list of individual element properties.
5. Parsing the name of the element and window wrapper function.
6. Returning the value of an element parameter to a variable of its type.
7. Setting values to element parameters of different types.
8. Returning, changing and forwarding values between parameters of different elements. 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 for setting ON, OFF, LOCK_ON, LOCK_OFF, LOCK, UNLOCK states for different element types.
11. test of binding and synchronisation of changing values of elements: e.g. input field with buttons and slider. So that when the value of one element (manual or software) changes, the value in the second element changes accordingly.
12. Testing of software obtaining/setting of range boundaries of the slider and the field with buttons (properties _V_MIN, _V_MAX, _V_STEP, _DIGITS).
13. Testing the operation of the item status query (_GET_STATE).
14. Linking text and border colours to spaced value boundaries.
15. Orientation in the API file.
16.Implementation of simple program logic of message and warning windows appearance.
//------------------------------------------
The topics that have been considered are highlighted in yellow.
For the current moment there are some left to be considered:
14. Linking text and frame colours to spaced value boundaries.
15. Orientation in the API file.
16.Implementation of simple program logic of message and warning windows appearance.
//------------------------------------------
I suggest linking topic 14 with topic 16. Going beyond the set limits of parameter values will first cause signals in the form of changing the colour of parts of elements (text, base, frame, stripe, etc.), then opening a dialogue window, and then a warning window. At the same time, the warning window will block changes to values in elements until it is manually closed by the user.
Also, I'd like to add a theme to the list:
17. cancelling entered settings when the user clicks on the "Cancel" button.
A long time ago, the technology of cancelling user settings by clicking the "Cancel" button was developed and to some extent tested. At the moment, it is not known how much the former functionality works. Therefore, a test is necessary.
As a result of the overlap of topics, the order of review will be as follows:
14. Implementing staggered parameter boundary protection:
15. Let's consider the new API file printout in detail.
//----------------------------------------------------------------------------------------------------
Next, I will collect all the bugs or defects found and make a list of tasks for the next release.
After the next release with fixes and additions, I will focus on the tables, in which I see one of the main directions of further development of the engine.
I've spent the last week learning how to write an interface using WinForm and build it into MT5 charts. Today I finally figured out how to do it.
And how will you make the interface communicate with your programming code?
And how will you establish a connection between the interface and your programming code?
A few more questions:
In principle, everyone can use the tool they are comfortable with. I am comfortable with my interface and that is why I am developing it. In other words, I am going to use it in my own algorithmic trading. Publishing solutions on the forum adds motivation. If my interface turns out to be useful to someone - fine, if not - it won't hurt me.
In the interface I see a powerful tool, which, combined with the algorithmic capabilities of MT5, will allow me to scale the results of correct trading. Yes, in this long way, I am "going to market". It takes years, but in any case, it takes me time to develop intellectually. There's no point in trading the market with money but no brains, is there?
The decision to use WinForms, or something similar, is in my opinion incomplete in nature. It leads to technical detachment from MT5 and building an independent multi-window Windows application. At the first stage it will be connected to the platform by a data channel like an umbilical cord. The user will wiggle with DLL polls and may even be successful. If desired, he will be able to create a context menu, and use some templates for quick creation of windows..... But in the end..., he will work in two or three IDEs at once, and in different programming languages. So how is it better? And more importantly - how is it easier?
Besides, having a multi-window Windows application, the user can directly connect it to the API of another trading platform. So it will be easier for him than working through a timer. And the market should be mentioned. His product will not be allowed there. In general, to each his own.