Discussion of article "Continuous Walk-Forward Optimization (Part 7): Binding Auto Optimizer's logical part with graphics and controlling graphics from the program"

New comment
 

New article Continuous Walk-Forward Optimization (Part 7): Binding Auto Optimizer's logical part with graphics and controlling graphics from the program has been published:

This article describes the connection of the graphical part of the auto optimizer program with its logical part. It considers the optimization launch process, from a button click to task redirection to the optimization manager.

As already mentioned earlier, ViewModel is the connector between the graphical part of the application and the software implementation of the logic. It is the program graphics representation, which implements application logic calls and graphics reaction to the callbacks of the logical part of the application. Accordingly, a public property from the ViewModel part corresponds to each editable field in the graphical part of the application. These properties can either be getters, in which case they cannot be changed from the graphics, or setters, which allows overwriting the object hidden behind this property. In previous parts, we have already considered in detail the data binding technology. Therefore, I will only provide a few examples here. 

Text fields are connected using properties that have both write and read access. As an example, consider a field that indicates the name of an asset on which optimization will be performed. The XAML markup for this field is extremely simple.

    
<TextBox Width="100"
         IsEnabled="{Binding EnableMainTogles, UpdateSourceTrigger=PropertyChanged}"
         Text="{Binding AssetName}"/>

In addition to setting the width of the text window, it also has fields IsEnabled and Text. The first one sets whether the field is available for editing. If it is set to true, the field becomes available for editing. If it is false, then the field is locked. The "Text" field contains the text entered in this field. Then, there is a construction in curly braces opposite each of them. Its content sets the connection of the object with a certain public property from the ViewModel class specified after the "Binding" parameter.

Author: Andrey Azatskiy

 

You have again demonstrated your high professional level as a programmer. A little more usability, so to speak, for more popularity. To understand these articles you need a commensurate amount of time spent on writing them. Would you put your optimiser in kodobase, just as code and instructions for use? Perhaps it will be noticed by more traders.

I see that the custom optimisation criterion has not appeared yet and the height in the calendar..... Since OnTester() is used mandatorily, we could do with just the custom criterion at all. And once again I want to ponder about automating the input of testing periods. My practice shows that it is better to perform test forward optimisation on periods of 3-5 weeks on several instruments. Writing manually all the periods for each piece is not for the faint-hearted. It is not difficult to create a script using MQL5 tools to receive and output periods, but due to sandbox and format limitations, you will have to manually transfer them to the Auto-Optimiser. You can do it in the functionality of the programme. You may not need it personally, but who have you written such large and complex articles for?

Reliable operation is the advantage of your Auto Optimiser over its well-known analogue, while the complexity of setting it up is a disadvantage. But you have a manual for those who find it.

 
Good Beer:

You have again demonstrated your high professional level as a programmer. A little more usability, so to speak, for more popularity. To understand these articles you need a commensurate amount of time spent on writing them. Would you put your optimiser in kodobase, just as code and instructions for use? Perhaps it will be noticed by more traders.

I see that the custom optimisation criterion has not appeared yet and the height in the calendar..... Since OnTester() is used mandatorily, we could do with just the custom criterion at all. And once again I want to ponder about automating the input of testing periods. My practice shows that it is better to perform test forward optimisation on periods of 3-5 weeks on several instruments. Writing manually all the periods for each piece is not for the faint-hearted. It is not difficult to create a script using MQL5 tools to receive and output periods, but due to sandbox and format limitations, you will have to manually transfer them to the Auto-Optimiser. You can do it in the functionality of the programme. You may not need it personally, but who have you been writing such large and complex articles for?

Reliable operation is the advantage of your Auto Optimiser over its well-known analogue, while the complexity of setting it up is a disadvantage. But you have a manual for those who find it.

Thank you for your comment. As I wrote in the conclusion to the article, I will add all the additions in the last article. This is one of the previously planned ones. I tried to describe in all articles that are published - the whole programme from the part that uploads reports to the internal structure of the auto optimizer itself. I remember about the promised edits and I am already working on them. However, I will publish them in the next article, as I had to complete the description of the first version of the programme first. As I remember a teacher at university used to tell us: "A car manufacturing company will not change the brake system for a new one on the already produced version of cars".
Regarding the code, it is attached to the article and you can change it, disassemble it and modernise it if you need it (I will make the promised edits, and if you need something more individual, you can add it as a variant or just work it out if you are interested), that's why I write it in such detail that there would be a picture of how everything works. I will add automatic period splitting.

New comment