
You are missing trading opportunities:
- Free trading apps
- Over 8,000 signals for copying
- Economic news for exploring financial markets
Registration
Log in
You agree to website policy and terms of use
If you do not have an account, please register
Yeah...it's all the same in principle...
The new build has stopped copying simple structures in the loop. Here is a test script:
Result:
2011.11.13 09:30:44 Test_Copy_Struct (EURUSD,M15) Access violation read to 0x00000000209FFFAC in 'E:\Program Files\Championship_2011\MQL5\Scripts\Test_Copy_Struct.ex5'
2011.11.13 09:30:44 Test_Copy_Struct (EURUSD,M15) i=0
2011.11.13 09:30:44 Test_Copy_Struct (EURUSD,M15) LossToReverse=3000.00 MAPeriod=100 MA_use=1 Lots=0.10 takeprofit=1000
2011.11.13 09:30:44 Test_Copy_Struct (EURUSD,M15) Setting reopened=110 overpos=130 TrailingStop=200 WithoutlossLevel=1300 WithoutlossProfit=1500
2011.11.13 09:30:44 Test_Copy_Struct (EURUSD,M15) ------------------------------
2011.11.13 09:30:44 Test_Copy_Struct (EURUSD,M15) LossToReverse=1000.00 MAPeriod=85 MA_use=0 Lots=0.15 takeprofit=1700
2011.11.13 09:30:44 Test_Copy_Struct (EURUSD, M15) Setting reopened=110 overpos=140 TrailingStop=200 WithoutlossLevel=600 WithoutlossProfit=800
2011.11.13 09:30:44 Test_Copy_Struct (EURUSD,M15) ------------------------------
2011.11.13 09:30:44 Test_Copy_Struct (EURUSD,M15) LossToReverse=2000.00 MAPeriod=105 MA_use=1 Lots=0.13 takeprofit=2700
2011.11.13 09:30:44 Test_Copy_Struct (EURUSD,M15) Setting reopened=60 overpos=90 TrailingStop=1000 WithoutlossLevel=100 WithoutlossProfit=900
2011.11.13 09:30:44 Test_Copy_Struct (EURUSD,M15) ------------------------------
2011.11.13 09:30:44 Test_Copy_Struct (EURUSD,M15) LossToReverse=0.00 MAPeriod=0 MA_use=0 Lots=0.00 takeprofit=0
2011.11.13 09:30:44 Test_Copy_Struct (EURUSD,M15) Setting reopened=0 overpos=0 TrailingStop=0 WithoutlossLevel=0 WithoutlossProfit=0
https://www.mql5.com/ru/docs/basis/function/events says at the end:"For a better understanding it will be useful to run the indicator whose code is attached below. "
Run the code. Over the weekend. No better understanding happened - it was fine as it was, I think, but the worst impressions were added. There are no ticks at the weekend, so prev_calculated = 0 at this time always, when moving from timeframe to timeframe:
However, at one point this value appears (no reconnects, honestly noble!):
and funny lines on the chart:
Or half as much fun, like this:
There were even lines at the beginning of the story in the form of a ZigZag (alas, I forgot to take a screenshot and could not reproduce it).
Lines also appear on other TFs, but more sparsely. You can easily see it for yourself.
Was it exactly what the authors wanted to say?
Why is the result of prev_calculated at least unequal in absence of ticks, if not strange? Is something crashing when jumping from TF to TF?
Should these (or any other) lines have appeared outside the ticks?
In rare cases, can relatively frequent jumping from TF to TF generate some sort of pseudotick that initiates the calculation of bar values on history, etc.?
Should I expect that the terminal's erratic behaviour will be eliminated? Or should I learn the math?
Maybe I'm trying to do something I shouldn't want to do? In that case, justify your point of view.
There are a lot of questions... but this is just the beginning...
Continued...
On the same link there is a phrase:"Note: if OnCalculate function returns null value, no indicator values are shown in the DataWindow of the client terminal. "
Here's the thing... If need be, I will gladly agree to any arm growth and immediately run to straighten it if necessary. But. In simple and medium-complexity indicators you can still somehow get out of some jamming situations. But as the code becomes more complex, any function of Copy... () (both taking a handle of another indicator as an argument, and without it) begin to complicate the situation, as I personally think, dealing with MQL programming a week ago. Then a threshold moment comes when one doesn't know what else can be changed in the code, because everything that can be changed has been changed, and the rest, as it seems to me, must not be changed, because it has nothing to do with the problem. Or an absolutely disarming thought occurs: to change the entire algorithm, because the peculiarities and vagaries of the terminal have not been taken into account. After all, while studying MQL through documentation, you have to deal with the nuances, which developers have kept silent, most likely inadvertently. And the MQL programmer never learns a lot of things after studying the documentation completely... And what's most disappointing, using MQL, you either can't correct many of the terminal's vagaries at all, or you can use dubious crutches and one day crash painfully...
Well... I've gone a bit crazy today. It's the weekend.
And here's what I wanted to tell you this morning...
https://www.mql5.com/ru/forum/1111/page570#comment_117425 - I have completely solved the main problem of how the indicator is not rendered at the initial terminal start (I hope nobody will argue that nothing should prevent a fractal indicator from rendering correctly on the whole history even if there are no ticks?)
It was:
replaced by:
I admit my inattention and consequent pernicious formalism.
But. It helped in the most simple case (I purposely simplified the initial indicator). In a more complex indicator these operations were not helpful - at a certain moment the changes did not show any difference, especially now that there are a lot of copying functions. And I would very much like to get a sensible instruction on how and where to go next. After all, so much time is spent on something that works out of the box. So far, I don't even know whether it's my fault or the terminal's. And I'm not sure it's just a lack of ifs andreturns... Looks suspicious here and there, like else, for example...
I'll send the code to developers in my personal if necessary; I can also attach a similar code, but implemented in a different way and it works without problems (although, it doesn't quite fit the tasks and goals I'm exploring).
There's a strong suspicion that the terminal is messing with the cache (I'm almost out of the loop, so...). Worse - even MetaEditor somehow affects the handling of what's going on in the terminal at the time.
More than once I've encountered a problem, when I modified the code of MQL program (that prints debugging data into Expert Advisor tab log), recompiled it, went to Terminal window and saw the previous results repeating, although I can definitely say that it is not some kind of delayed rework of previous uncompleted program run. So, I compile and send the updated code to MetaEditor with F7, and meanwhile the terminal gets the command to replay the old code (from cache, or something like "fudging" memory pages by OS). Interestingly, it is possible to undo/unload "stuck in the teeth" previous version of .ex5-code not only by completely unloading terminal.exe process, but in some rare cases - just by closing MetaEditor. Understand it as you want, I just recounted what I personally observed.
Recently, there was a situation when the design:
The chart displays only the value of the first Print, but it was useless to wait for the output of the array elements. After the removal of the first Print and recompilation the cyclical output of array items started instantly. Is it a secret conspiracy of Prints against the MQL5-Community or am I the only one who has such bad luck?Additionally, I want to point out that these strange cases of terminal's behavior were observed not on an MT5 instance overloaded with chart windows, graphical objects and MQL programs, but with a single clean chart window (not counting the outline of a running indicator).
1. The ArrayInitialize code is not working, if I uncomment the loop, everything is fine.
And when declaring variables in class and indicator on global level with the same name - warning pops up.
1. The PlotIndexSetDouble(z,EMPTY_VALUE) is used for indicator buffers in the inite.
2. It pops up. Then something should be done about it, it is recommended to mark class members with the "m_" prefix.