Gallery of UIs written in MQL - page 59

New comment
  
#include<(2)  KIB PROJECTS\(6) DEMO PROJECTS\Demo project 1.mqh>

Demo project 1 is included in (1) KIB-source v1, but why don't I see the related window on the diagram?

 
hini #:
The catalogue is still in Russian ...... I hope it is possible to have the catalogue and file names in English as KIB PROJECTS ....... This is a small request from me!
Of course, I will translate the catalogues into English before uploading to kodobase. I just haven't had the time. This is an interim version for public testing.
 
hini #:

Demo project 1 is included in (1) KIB-source v1, but why I don't see the associated window in the diagram?

That's strange. I'll check it now.
 
hini #:

Demo project 1 is included in (1) KIB-source v1, but why I don't see the associated window in the diagram?

Checked the assembly. Demo-project 1.mqh is located here:

(2) KIB PROJECTS\(6) DEMO PROJECTS\Demo project 1.mqh


 
I'll do a full breakdown of the release a little later.
 

Yesterday, after downloading the new version, after a lot of work and being on an emotional high, I wrote a very positive post literally praising the new functionality. Such enthusiasm is not very appropriate in the context of a strict technical discussion. Today I want to look at the implemented solutions in a calm and unbiased way. I will welcome constructive criticism and objective evaluation. It is important for me to get clarity on the point of view of third-party users. Feedback will help to make adjustments and improvements. And of course, to detect and fix bugs.

 
Let's get to the breakdown of the release.
 
I'll start on a new page so that important information stays in view longer.
 

The task was set to implement programmatic interaction of user code with the graphical interface of the programme.

According to the idea:

  • After writing and debugging the KIB code, the user gets the desired result (in the form of ready windows) and saves the project.
  • As a result of generation there are two files: technical UIDATA.mqh and "API.mqh". The first one is necessary for loading and operation of the interface, the second one - for fixing events of elements.
  • The user transfers both files from the Files folder to his project (currently: KIB PROJECTS\(5) USER PROJECTS\Project 1).
  • Compiles your Expert Advisor or indicator with the lines connecting the engine and both files:
//+------------------------------------------------------------------+
#include<(1)  KIB 1.0\(4) CONNECTIONS\KIB-DRIVE CONNECTIONS.mqh>
//--------------------------------------------------------------------
#include<(2)  KIB PROJECTS\(5) USER PROJECTS\Project 1\UIDATA.mqh>
//--------------------------------------------------------------------
#include<(2)  KIB PROJECTS\(5) USER PROJECTS\Project 1\API.mqh> 
//+------------------------------------------------------------------+
  • Throws the EA on the chart and sees the interface.
The EA Shell v1.mq5 is used as an example in the demo project , which "represents" a user programme. It has identical connections that are necessary for the user analogue .

//----------------------------------------------------------------------------------

However, prior to this release, the user could only receive events of interactive elements in a subkeyed API file.

It is important to emphasise: the user did not have many, absolutely essential software features.

I will list:

  • Programmatically open/close GUI windows.
  • Get/set values in the parameter of different types of elements.
  • Switch states of elements programmatically: for example,switch on/off, lock/unlock elements at user actions or at external events fixed by the running Expert Advisor/indicator.
  • Programmatically get/set other values of element properties: base, text, frame colour. Change the icon.


This update solves almost all the tasks set.

Let me list them:

.
  • User can open/close GUI windows by program call.
  • The user can get/set values in the parameter of elements that have it. Including non-interactive elements such as table cells (CELL) and text labels with a parameter (VALUE).
  • Programme switching between two and four states of different types of elements is implemented. For buttons and checkboxes four states of software switching are available (on/off/locked on/locked off), for other elements - two (locked/unlocked).
  • Small sets of individual element properties are available for programme return/set values. Each set is represented by a prefix from opens with an intellisense list. It generalises a small, related group of elements having similar properties. This approach eliminates confusion in the multitude of properties of different types of elements.
  • Programmatically setting a value to a parameter sends the event to the element's location in the API file, where the user can write additional code to handle it.
  • Table cells are named automatically by folding the name of their row and column. They get a name and functional wrapper in the UIDATA.mqh file. However, they are not present in the API file because they are not interactive elements. They can be found in the list of window elements and otherwise respond to software control like all elements.


Due to the possibilities of program control, things that were not available before are realised:

1. Value dispatch. Getting the value of one element and forwarding it to other elements in the same, or another window.

2. Software opening of warning and dialogue windows. For example, in a situation when it is necessary to display an urgent message or a recommendation to a user.

3. Obtaining a general picture of settings and execution status through queries of element parameters. Can be used as a complement to analyses of other program parameters.

4. Dynamic resetting of programme settings without interrupting the work process.

5. Thanks to the possibilities of changing the colours of bases, text and frames (no frames yet), the interface becomes more interactive and informative. For example, when you rewind a value and it gets into the risk zone, the input field with buttons can signal the user about the danger by red colour of its base or text. This is now easy to implement. The same applies to the slider bar. In the zone of dangerous values, you can programmatically change the colour of the bar. It turns out to be interactive, informative and practical.


At the moment I haven't fully realised all the upcoming possibilities and I'm sure there's a lot more to come.


Next, let's move on to the practical part of breaking the new version.


 

As it turned out, the practical part of the demo is quite extensive and its coverage will take time. I will tell and show the new features in detail and in an accessible way, with comments, pictures and gifs. I may have to divide the presentation into two days - today and tomorrow. That's okay, your understanding will improve. You should have a rest too.


The plan of parsing the functionality of the new version of the engine:

1. I remind you that new folders and files should be installed in ME after the complete erasure of the previous ones. There is no need to make replacements.

2. To work we need to open files (1) EA Shell v1.mq5 and API.mqh . There is no need to open other files. We will use the same interface and familiar windows from Demo project 1.mqh. The first file should be in the Experts folder (I think it is already there), and the second one can be found here:



UIDATA.mqh and API.mqh file in this folder already contain everything you need. There is no need to generate new files in the constructor.


3. The main work will take place in file (1) EA Shell v1.mq5, in the functions _OnInit() and _OnTimer, but sometimes we will look into the file API.mqh. If you're curious, you can open the UIDATA.mqh file and see what the window and element wrapper functions look like. They are printed at the very bottom. Otherwise, this file is not needed for work and can be closed.


The topics we'll cover are:

1. navigating the list of intellisense and selecting the right window function.

2. Programmatically opening and closing windows.

3. Orienting in the list of intellisense and selecting the right feature in the right window.

4. navigating through lists of individual element properties.

5. Parsing the name of the 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 to 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.


That's all for now, but additions are possible as we go along.

1...525354555657585960
New comment