Share Class data from EA with [to] an Indicator

[Dennis Jorgenson]

So I have a Class Object (TickMA) that aggregates tick data in proprietary fashion. The class object is instantiated and updated from my EA. Problem: I want to visually present data contained in the EA Class to an separate window indicator.

Looking for a way to pass the pointer from the EA to the indicator (if/while open) so that the indicator precisely paints the data the EA is operating on.

The TickMA indicator below uses 8 buffers and paints data from a multitude of class methods. My 'quick fix' solution was to instantiate the same class with the same Constructor variables at the exact same time which works for the most part - where this fails is on those rare occasions when I need to restart the indicator without restarting the EA or feel the need to close the indicator during high-volume trading to reduce CPU overhead during the indicator repaint. 

In short, I want a single operable (open) Class object instantiated by the EA to be shared to any indicator used to present data used by the EA.

Help, hints, ideas are welcome.

[Carl Schreiber]

The EA is not meant or ready to pass data to indicators. But everything an indicator shows on a chart or separate window can be passed to every EA the loads this indicator with iCustom().

Here is an introduction and here are quite a lot further of articles how to write your own indicators, no matter whether their data are in separate windows or the main chart.

Use them to copy, paste, and amend what you need.

[Dennis Jorgenson]

Carl Schreiber #:

The EA is not meant or ready to pass data to indicators. But everything an indicator shows on a chart or separate window can be passed to every EA the loads this indicator with iCustom().

Here is an introduction and here are quite a lot further of articles how to write your own indicators, no matter whether their data are in separate windows or the main chart.

Use them to copy, paste, and amend what you need.

Thanks. Exactly what I figured. Problem with this is that iCustom is stateless and executes the Class Constructor every tick purging [unrecoverable] aggregation analytics. Would be nice if Class Objects in memory could be accessed by Globally.

[Fernando Carreiro]

Dennis Jorgenson #: Thanks. Exactly what I figured. Problem with this is that iCustom is stateless and executes the Class Constructor every tick purging [unrecoverable] aggregation analytics. Would be nice if Class Objects in memory could be accessed by Globally.

Then redesign your indicator taking its functionality and interoperability with an EA into account.

Also, a class constructed at every tick is not a very good way to program it. You need to rethink your logic.

[Lorentzos Roussos]

You can also turn the ea to a "data hub" and the indicators that display the data to "data subscribers" . Then do the initial heavy loads via the filesystem , and send the live data via chart events .

[Dennis Jorgenson]

Fernando Carreiro #:

Then redesign your indicator taking its functionality and interoperability with an EA into account.

Also, a class constructed at every tick is not a very good way to program it. You need to rethink your logic.

Come again? As far as I'm aware, the 'expected' way of retrieving data from an custom indicator is by using iCustom - which - in turn, is stateless meaning each call recomputes buffer values as if the indicator were opened (instantiated) for the first time. Further, by limiting the data interchange to a data 'bus' consisting of buffers while not exposing Object Model calls (methods/properties) defeats the purpose of OOP use in a custom indicator by restricting Class Object utility.

Am I missing something?

[Dennis Jorgenson]

Lorentzos Roussos #:
You can also turn the ea to a "data hub" and the indicators that display the data to "data subscribers" . Then do the initial heavy loads via the filesystem , and send the live data via chart events .

This is the way. Exactly how I implement today - the EA instantiates and manages all Class Objects and then 'reports' data to the indicator labels. This works well (enough) - was really hoping for an 'elegant' solution to populate the indicators data buffers.

[Fernando Carreiro]

Dennis Jorgenson #: Come again? As far as I'm aware, the 'expected' way of retrieving data from an custom indicator is by using iCustom - which - in turn, is stateless meaning each call recomputes buffer values as if the indicator were opened (instantiated) for the first time. Further, by limiting the data interchange to a data 'bus' consisting of buffers while not exposing Object Model calls (methods/properties) defeats the purpose of OOP use in a custom indicator by restricting Class Object utility.

Am I missing something?

For MQL4, Indicators called by iCustom() are cached (as long as the passed parameters do not change) and only released when the EA terminates. They are not instantiated on every call, except when indicator parameters change.

For MQL5, a handle to the indicator is maintained until it is released on command by the user code or when the expert terminates.

You can exchange data between the Indicator and EA in various ways:

• Via the buffers (you can use union to pass other data-types or small structures instead of the normal "double" data-type).
• By using custom chart events.
• By shared hidden Graphic Objects on the chart.
• By Global Terminal Variables.
• By shared files.
  

You can wrap the above in OOP if you so wish.

[Lorentzos Roussos]

Dennis Jorgenson #:

This is the way. Exactly how I implement today - the EA instantiates and manages all Class Objects and then 'reports' data to the indicator labels. This works well (enough) - was really hoping for an 'elegant' solution to populate the indicators data buffers.

Clever .

You can write to the HDD for the initial loads , and , send the rest this way or via chartevents.

HDD method is not that slow and quitte handy for primary loads .

Your only issue might be when an indicator loads and "subscribes" , you might not want to open up the entire database so you may need to arrange that data in "blocks" and load what you need . 

Then you have save intervals in the EA (that acts as the hub) ,so any subsequent "primary" loads pull from the hdd.

[Paul Anscombe]

I use custom events to move data between indicators and eas etc and files to maintain status between shutdowns etc

Works well

[Shephard Mukachi]

Paul Anscombe #:
I use custom events to move data between indicators and eas etc and files to maintain status between shutdowns etc

Works well

Hi Paul,

I hope you're well.  I think I could possibly figure this out through testing, but given you're using the 'custom events' approach I wondered if you could help me.  I've been having a hard time synchronising multiple timeframes in one indicator.  There seems to be some acrobatics that must be peformed, or maybe I just lack adequate understanding, or both.

From my understanding, MT5 indicators are async - which is good in the caller does not have to wait for data to be loaded.  But this 'not waiting' presents an issues, if indicator is accessing HTF series, using CopySeries, CopyClose etc. - it does not always load.  Weekends are particularly worse when the OnCalculate is not fired when markets are closed.  I have seen Anatoli Kazharski' workaround, it's ugly.  I have not tested it, but I do not have a reason to believe it does not work.  Have you encountered issues regarding multiple timeframes in indicators?

I have used checks as provided by the documentation https://www.mql5.com/en/docs/series/timeseries_access, but theses methods do not work either.

So with your approach of using 'custom events'  what would happen if the indicator reloads, setting prev_calculated = 0?  When I think of that mechanism, especially if working with 2 timeframes, what if say D1 indicator resets/reloads, but the H1 Indicator does not?  This mean that they are out of sink?

Maybe, I'm just tired, or lack adequate understanding of MT5 indicators work.

Any ideas will be greatly appreciated.

Thanks,

Shep