does init()/start() called everytime i call iCustom

 

hello, one of my friend ask me to create lite protection scheme on his EA... i put some online validation in the custom indicator...

Now i would like to know about how EA workflow when it call iCustom in everytick:

does init() triggered again ?

does start() triggered again ?


because if its triggered.. there might be high data request to his server on everytick when a lot of people using the indicator.. any thought ?

 

init() is triggered once during the EA startup. start() is triggered on every tick.


The traffic to the server is generally light if you are querying things like AccountEquity() which I would expect to be already cached somewhere. But whatever you are doing, you can keep an eye on the traffic to/from the server by observing the Connection status kb display at the bottom right of the window.


As far as the "data" (you mean tick data?) is concerned, the data is received and stored locally on the PC and used by whatever calculations you are doing inside the indicator. You would (should) also have used the Bars and IndicatorCounted() values in the indicator to avoid unnecessarily re-calculations.

 
The question is regarding the indicator init() and start(). Can anybody help?
 
AnkaSoftware:
The question is regarding the indicator init() and start(). Can anybody help?

the question really is not about init() or start(). Far from it.

Its about:

"...there might be high data request to his server on everytick when a lot of people using the indicator.. any thought ?"

meaning to say, what logic and IO in indicator, will determine. Its quite normal for a malformed indicator to crash MT4 on a PC, I don't see why it can't on a server load.

 
veeco:

Now i would like to know about how EA workflow when it call iCustom in everytick:

does init() triggered again ?

does start() triggered again ?

The first iCustom call (with unique parameters) - loads the indicator if not already on the chart, init and start are called, then the requested buffer value is returned.

On subsequent iCustom calls the buffer value is returned. The indicator is unaware.

on a new tick, all indicator's start is called, then all idle EAs start are called.

Indicators can NOT sleep and must return quickly as they run in the GUI thread. On-line validation violates this.

 
WHRoeder:

The first iCustom call (with unique parameters) - loads the indicator if not already on the chart, init and start are called, then the requested buffer value is returned.

On subsequent iCustom calls the buffer value is returned. The indicator is unaware.

on a new tick, all indicator's start is called, then all idle EAs start are called.

Indicators can NOT sleep and must return quickly as they run in the GUI thread. On-line validation violates this.


from the documentation:

At incoming of new quotes, the start() function of the attached experts and custom indicators will be executed. If the start() function launched at the preceding quote was running when a new quote came, the new quote will be skipped by the expert. All new quotes income while the program was being executed are skipped by the program until the current execution of the start() function has been completed. After that, the start() function will be run only when a successive new quote incomes.

From how you explain, you are saying that a custom indicator will kick start() on EVERY NEW TICK, irregardless whether it has completed its previous start().

Is that really the case for custom indicators, bearing the fact NOT the case, for EA as mentioned clearly (the new quote will be skipped by the expert)?

How do you guarantee that indicators (even more so for iCustom) drop their previous start() operation and when a new tick come?

 

I did some tests -

a) If indicator input parameters are added to the iCustom call, the indicator assumes a fresh set of inputs are coming and it inits() each time iCustom is called from the EA.

b) Without the indicator parameters in the iCustom call, the indicator inits() only once at the first iCustom call.

Any workaround / suggestions to prevent indicator from init()ing, each time iCustom is called with input parameters?

 
diostar:

From how you explain, you are saying that a custom indicator will kick start() on EVERY NEW TICK, irregardless whether it has completed its previous start().

How do you guarantee that indicators (even more so for iCustom) drop their previous start() operation and when a new tick come?

Indicators can not sleep, they must return quickly.

If the indicator does not return, the terminal is DEAD. There is NO next tick.

The next tick can only be read by the terminal once ALL indicators have returned.

 
WHRoeder:
The next tick can only be read by the terminal once ALL indicators have returned.

If the previous iCustom start() is still in processing, all coming ticks will be missed, until it finishes and return, then the next new tick kicks in start().

If it does not return quickly due to still being "stuck" in the previous start(), this affects the interface thread, and hence causes freezing.

Reason: