Discussing the article: "Improve Your Trading Charts With Interactive GUI's in MQL5 (Part III): Simple Movable Trading GUI"

New comment
 

Check out the new article: Improve Your Trading Charts With Interactive GUI's in MQL5 (Part III): Simple Movable Trading GUI.

Join us in Part III of the "Improve Your Trading Charts With Interactive GUIs in MQL5" series as we explore the integration of interactive GUIs into movable trading dashboards in MQL5. This article builds on the foundations set in Parts I and II, guiding readers to transform static trading dashboards into dynamic, movable ones.

Hello and welcome back to part 3 of our series "Improve Your Trading Charts With Interactive GUI's in MQL5".

Before we venture into new territory, let's quickly recap what we've covered in Parts I and II:

1. In Part I, we started by understanding the concept of chart events, and from there, we created two simple movable dashboards on the same chart.

2. For Part II, we took a step further. We utilized classes within a .mqh file to make our code more efficient and versatile, ready for integration with full-scale EAs/Indicators.


And now, we are ready for Part III! In this part, we're going to focus on enhancing our dashboards by integrating GUIs into them. Because without GUIs, dashboards won't serve their intended purpose.

Author: Kailash Bai Mina

 

Hi Kalish,


Interesting approach and congratulations on finishing your series.  The OnEvent coding is what makes it all happen!  As your first article got me excited, I developed my one version of the movable panel.  It is a base class that is inherited by individual classes for each panel type.  Secondly, as I had already created a controls header file that was based on examples in the MQL help file, I chose to use it instead of creating a Text class for inheritance and it worked well.  I am planning on creating two more methods for the GUI class, Save and Initialize.  Save will read and update a CSV file and set the starting location positions and data.  Initialize sill read the CSV file and and set the initial positions.

For your review I am attaching a screen shot of my current EA headings and two Panels.  The first is the Active Orders that I will be using and the Sample is the bare bones version used as s template for additional Panels.


Good Luck in your future endeavors, I'll be watching


Cape Coddah

 

The article was really good. Well didactic and explained. I liked. 😁👍

 
CapeCoddah #:

Hi Kalish,


Interesting approach and congratulations on finishing your series.  The OnEvent coding is what makes it all happen!  As your first article got me excited, I developed my one version of the movable panel.  It is a base class that is inherited by individual classes for each panel type.  Secondly, as I had already created a controls header file that was based on examples in the MQL help file, I chose to use it instead of creating a Text class for inheritance and it worked well.  I am planning on creating two more methods for the GUI class, Save and Initialize.  Save will read and update a CSV file and set the starting location positions and data.  Initialize sill read the CSV file and and set the initial positions.

For your review I am attaching a screen shot of my current EA headings and two Panels.  The first is the Active Orders that I will be using and the Sample is the bare bones version used as s template for additional Panels.


Good Luck in your future endeavors, I'll be watching


Cape Coddah

I am glad you are benefitting with my articles.

Actually You motivated me to write this part 3 otherwise it would have taken more time due to lack of motivation.

Thank you very much for that.

Good luck to you too for your future endeavours.

 
Daniel Jose #:

The article was really good. Well didactic and explained. I liked. 😁👍

It’s my pleasure. Thanks for your time.

 

Hi Kailash,

I hope you monitor this article as I do not know how to private text.

Anyway, I I have really incorporated your concepts into a much better way of organizing an EA.  Here is a screen shot of my old version and one using your moveable Panel concept using your part 2 concepts with multiple children.  While it is still in the preliminary development stage, it will allow me to display more pertinent data during model testing.

Right now I have a separate child class for each panel, including the Controller.

clsGUI  GUI;
clsAO   AO;
clsBOB  BOB;
clsCTL  CTL;
clsXO   XO;
clsATR  ATR;
clsRSI  RSI;
clsMM   MM;
clsTS   TS;

//clsAO Guis[egElements];
//clsGui GuiS[egElements];
//object Guis[egElements];

While this approach is adequate, it leads to many separate functions to handle various tasks in the EA panels.  A better approch would be to have  an array of the children and use it as a parameter in the reduced function calls.  I have tried using the first two approaches but I cannot cast the elements of array to the appropriate child class in order to call its unique public functions.  I had limited success in accessing public variables by using a wrapper class  with the object declaration.  Thiis approach seems to use the elements class definition of the parameter element rather that the class definition of the Array 

int Wrapper(object &theobject){

return(theobject.aninteger):

}

int i=Wrapper(Guis[5]);

this approach does not work for Guis[5].Create_Controls(......);

The only approach that I have seen that works is to use c_array to create an array of object pointers and add them to the array. and then access by a function that calls the c_array AT(location) function to assign the array pointer to a local  pointer of the object declared locally to access the child variables locally.

Do you or anyone know how to solve this issue or provide a reference to MQL articles or documentation that address an array of child classes rather than an array of one class?

Many many thanks and I am looking forward to your next articles

CapeCoddah

 

A good example of using OOP for OOP's sake.

It turned out to be cumbersome and not convenient (IMHO). But it works, which is already good :)


You should add OBJPROP_ZORDER otherwise buttons are pressed once in a while.

void Button::Create(string name, int xDis = 0, int yDis = 0, int xSize = 0, int ySize = 0)
  {
   ObjectCreate(0, name, OBJ_BUTTON, 0, 0, 0);
   ObjectSetInteger(0, name, OBJPROP_XDISTANCE, xDis);
   ObjectSetInteger(0, name, OBJPROP_YDISTANCE, yDis);
   ObjectSetInteger(0, name, OBJPROP_XSIZE, xSize);
   ObjectSetInteger(0, name, OBJPROP_YSIZE, ySize);
   ObjectSetInteger(0, name, OBJPROP_ZORDER, 1);
   _name = name;
  }
//+------------------------------------------------------------------+
 
Alexander Slavskii #:
ut it works, which is good :)

Thanks for the suggestion.

 
Aleksandr Slavskii using OOP for the sake of OOP.

It turned out to be cumbersome and not convenient (IMHO). But it works, which is already good :)


You need to add OBJPROP_ZORDER otherwise buttons are pressed once in a while.

This is not OOP at all. These are terminal methods re-wrapped in classes.

If a programmer wants to make a different GUI (fancy http, via WebSocket covered in other articles), he won't be able to do anything. He will just throw out all the code from the article and write another one.

To change the visual part radically, but on the same ObjectCreate(xx) - you will have to rewrite everything.

or how to disable GUI so that it doesn't take up CPU on VDS-ka.

Where is reusability ? Why GUI is interspersed with other code...We can't even talk about styles, at least colours.

Using the libraries of the article, the code of a typical EA has become shorter ? But no way, it was not written for that :-)

 
Maxim Kuznetsov #:

it's not OOP at all. These are terminal methods re-wrapped in classes.

If a programmer wants to make a different GUI (fancy http, via WebSocket covered in other articles), he won't be able to do anything. He will just throw out all the code from the article and write another one.

In order to radically change the visual part, but on the same ObjectCreate(xx) - you will still have to rewrite everything.

or how to disable GUI so that it doesn't take up CPU on VDS-ka

Where is reusability ? Why GUI is interspersed with other code...We can't even talk about styles, at least colours.

Using the libraries of the article, the code of a typical EA has become shorter ? But no way, it was not written for that :-)

Well, I think it is not quite correct to discuss colours here.

But the fact that the buy and sell buttons are placed in reverse, it can mislead the user.


It is not clear why the GUI should be switched off if it is a panel for manual trading. Although, if it is not a trading panel, but an informational one, then yes, it is better to consider disabling it.

I like the way RectangleLabel::OnEvent and RectangleLabel::Add functions are organised, it's beautiful, clear and readable.

I used the same principle in my panels, but my code was a little bit gaunt, or something. In general, it was not beautiful. So I decided to use the code from the article for a new panel.

The panel eventually turned out, but I spent more time on it than if I had written it from scratch.

In general, the conclusion is as follows: the article is interesting and useful, but the code in the article is partially not thought out.

 
Aleksandr Slavskii #:

Well, discussing colours, I don't think it's quite right to discuss colours here.

But the fact that the buy and sell buttons are placed in reverse, it can mislead the user.


It is not clear why the GUI should be switched off if it is a panel for manual trading. Although, if it is not a trading panel, but an informational one, then yes, it is better to consider disabling it.

I like the way RectangleLabel::OnEvent and RectangleLabel::Add functions are organised, they are beautiful, clear and readable.

I used the same principle in my panels, but my code was a little bit gaunt, or something. In general, it was not beautiful. So I decided to use the code from the article for a new panel.

In the end, I got the panel, but I spent more time on it than if I had written it from scratch.

In general, the conclusion is as follows: the article is interesting and useful, but the code in the article is partially not thought out.

There are a lot of elaborated methods with beautiful arrows "how to implement UI so that it would not be painful" :-) MVC and similar. So there front end (win,gtk,qt,web) can sometimes be changed with a slight movement of the hand.

None of them has been implemented in MQL. Everything is nailed down, worse than TurboVision - even though there are classes from Adam, but there are models there.

Individuals have been writing for years(!!!) about "easy and simple" and "simple interface", but it is exactly the same as in this article. A lot of code that does not make anything easier. The only effect is a bonus on the author's account.

123
New comment