Can an indicator called from iCustom be "busy"?
the indicator does not need to do anything when you call iCustom().
During the very first call to iCustom() it will be loaded (invisibly) and calculates all the values (and will from now on update them totally independently on its own as time goes by) and in all your subsequent calls to iCustom() you will only read the values from this invisible buffer without bothering the indicator at all.
not sure. does this only occur on bar 0?
Maybe also the indicator itself does some strange things and clears its entire buffer before calculating new values or something else along these lines that would fall into the category "race condition". Normally one would expect (but it isn't documented) that MT4 makes sure that on a new bar all indicators get their chance to update their buffers before the EA is allowed to read them but MT4 is full of nasty hidden bugs and I would not be surprised if this is one of them.
Of course without studying the complete code of indicator and EA all this can only be speculation. There might also be some simple error hidden in the logic of your EA.
Suggestion: Try to reproduce it with some minimal EA and minimal indicator: Make an indicator that will intentionally waste some time with Sleep(500) and then write the value of Close[0] to its buffer[0] and make an EA that uses it and Print(iCustom(....,0)); on every tick and put it on a few M1 charts and see what happens.
Indicators can not sleep.
if the EA doesn't return from start then race condition is easy
is the indicator stable at beginning of a new bar.
Indicators can not sleep.
They cannot sleep? They should not sleep! But we want to debug something and sleep should simulate a long-running calculation. I'm too lazy now to test whether it will silently ignore the Sleep() call but if this is the case then do a large for loop instead.
The whole question is: Will the iCustom() block until the indicator start() for this tick has returned (in other words: are the two threads synchronized properly)? Or alternatively is the indicator run in the EA's thread before the EA's start() or did they simply forget to think about this at all? As I already mentioned I am too lazy now, but the next time I am doing something with indicators and iCustom() I will try it.
PS: I'm almost sure they run all attached iCustom() indicators in the EA thread *before* EA start(), this would save them a lot of headaches in backtesting and avoid all the tricky thread synchronizing. This would also imply that the OP's question must be answered with "no, there cannot be a race condition, indicators are guaranteed to have finished before the buffer is read". But we have to test this hypothesis first.
Thanks for the replies guys... phew, it's a little hairy! 7Bit, you asked "not sure. does this only occur on bar 0?". You mean the very first bar (or tick) that I encounter after I start up my EA, you mean? I don't think so, but I will check.
In the meantime, I had an idea to test - I made a complete identical copy of my indicator - called it "MyIndicator2", and from my EA I will only do my iCustom calls to this one. The original "MyIndicator" will be the one that is applied and running on all my 16 charts, so "MyIndicator2" will be dedicated to just handling the iCustom calls. Let's see what happens.
Thanks!
Shawn
Thanks for the replies guys... phew, it's a little hairy! 7Bit, you asked "not sure. does this only occur on bar 0?". You mean the very first bar (or tick) that I encounter after I start up my EA, you mean?
Hi guys, just FYI, I made a little mod to my EA and it appears to have fixed up 95% of the problem (only rarely now do I get "0.00" returned). What I did was simply "prime" (for lack of a better word) my indicator by calling it with dummy input parameters during the INIT stage of the EA. For some reason, this seems to get it all "initialized" better so when it is called for real during the START function, it performs properly. Weird I know, but it seems to have worked.
It still however returns 0.00 rarely (I can live with this though). I was thinking of maybe putting a SLEEP(5) statement in between each call to the indicator... just to see if it makes any difference.
Thanks
Shawn
7Bit, it occurs not only on buffer[0] but all 7 buffers. All return 0.00.
This 0 is not the buffer number. It seems the errors you are getting is due to the fact that you don't have the slightest clue about what you are doing. You should again read the documentation (and the book), especially the parts dealing with arrays, indicator buffers and custom indicators. As long as you don't have an idea what an array is and how the indicator buffers are organized I doubt that you will be able to produce anything useful.
- Free trading apps
- Over 8,000 signals for copying
- Economic news for exploring financial markets
You agree to website policy and terms of use
Back again to nag the gurus ;-) I have about 18 charts up all running the same EA and also all with the same indicator on each chart. Within the EA, there is a place where I need to make several iCustom calls to that indicator consecutively to get values for the current bar, 1 bar ago, 2 bars ago... all the way to 14 bars ago. So 14 iCustom calls to that indicator one after another, bang bang bang. Most of the time there is no problem, but through Print statements, I've found that every now and then, those calls to iCustom return nothing (ie. 0.00). I'm thinking the indicator is too "busy" to handle the requests, because it's also concurrently being used in 16 other charts. Can this happen?
Thanks!
Shawn