Dependencies between indicators called in an EA

New comment
 

Hi!

I'm currently using two indicators in an EA (I'm novice) and would like to create a dependency between the two.


More specifically, I'd like that the result of the first indicator be used as one of the arguments of the second.


Indicators are however usually declared in OnInit (handles created using iCustom and fixed parameters), while their buffer data are stored in arrays in OnTick. That way of proceeding considers fixed inputs for both indicators (which is logic, for plotting purposes).


What would the most efficient/frequently used approach be to implement this (also in terms of memory use/speed, etc...)?

- replicating the calculations of the second indicator in a function (time consuming in terms of implementation and maintenance/alignment between the indicator and the function)

- defining a handle at each tick/bar (with a dynamic input value) instead of doing it in OnInit

- using a function encapsulating/calling the second indicator (which is similar to the second option)

- any other suggestion?

 
Thomas110:

Hi!

I'm currently using two indicators in an EA (I'm novice) and would like to create a dependency between the two.


More specifically, I'd like that the result of the first indicator be used as one of the arguments of the second.


Indicators are however usually declared in OnInit (handles created using iCustom and fixed parameters), while their buffer data are stored in arrays in OnTick. That way of proceeding considers fixed inputs for both indicators (which is logic, for plotting purposes).


What would the most efficient/frequently used approach be to implement this (also in terms of memory use/speed, etc...)?

- replicating the calculations of the second indicator in a function (time consuming in terms of implementation and maintenance/alignment between the indicator and the function)

- defining a handle at each tick/bar (with a dynamic input value) instead of doing it in OnInit

- using a function encapsulating/calling the second indicator (which is similar to the second option)

- any other suggestion?

So the first indicator gives you the parameters for the second indicator?

That is a challenge. You will be required to release the first handle and create a new handle. Do this only if the parameters actually change.

After getting the new handle, you need to wait for the indicator to do it's calculations before accessing it's buffer values.

A second option is, if you have the source code, to make the second indicator get its parameters from a global terminal variable and read that inside the indicator.

Now you can change the settings on the fly from the EA, changing the global terminal variable.


 
Dominik Christian Egert #:
So the first indicator gives you the parameters for the second indicator?

That is a challenge. You will be required to release the first handle and create a new handle. Do this only if the parameters actually change.

After getting the new handle, you need to wait for the indicator to do it's calculations before accessing it's buffer values.

A second option is, if you have the source code, to make the second indicator get its parameters from a global terminal variable and read that inside the indicator.

Now you can change the settings on the fly from the EA, changing the global terminal variable.


Yes that's correct. The second option would indeed be easier (two custom indicators with source code), thanks for suggesting; I didn't think about the use of global variables - some checks/precautionary measures would be needed though, as it can be risky.

I'm still trying to understand the entire logic, but I guess indicators are assessed when the CopyBuffer statement is executed. Then, if the latter function accepted (which is not the case) as arguments the input parameters of an indicator (as the iCustom function does), my question would be irrelevant and a global variable wouldn't be necessary. In some sense it could be seen as a limitation of mql5. Anyway, using a global variable would be much easier than duplicating an indicator into a function.

 
Thomas110 #:

Yes that's correct. The second option would indeed be easier (two custom indicators with source code), thanks for suggesting; I didn't think about the use of global variables - some checks/precautionary measures would be needed though, as it can be risky.

I'm still trying to understand the entire logic, but I guess indicators are assessed when the CopyBuffer statement is executed. Then, if the latter function accepted (which is not the case) as arguments the input parameters of an indicator (as the iCustom function does), my question would be irrelevant and a global variable wouldn't be necessary. In some sense it could be seen as a limitation of mql5. Anyway, using a global variable would be much easier than duplicating an indicator into a function.

There is no such limitations, you can create/release indicators handle as you want. But you need to know what you are doing to do it correctly, that's why the usual recommendation is to get the handle in OnInit().

The way to go depends of your exact needs, if you need to change the indicator parameters on each tick or once a day (as an example) are very different situations.

 
Alain Verleyen #:

There is no such limitations, you can create/release indicators handle as you want. But you need to know what you are doing to do it correctly, that's why the usual recommendation is to get the handle in OnInit().

The way to go depends of your exact needs, if you need to change the indicator parameters on each tick or once a day (as an example) are very different situations.

Thanks for your view. I'll perform some tests as it can indeed be rather risky or possibly not efficient if the frequency is at each tick.

New comment