![MQL5 - Language of trade strategies built-in the MetaTrader 5 client terminal](https://c.mql5.com/i/registerlandings/logo-2.png)
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
Does it make sense to
replace rates_total with BarsCalculated(ich)?
I don't think so. It's more like a service stub to make sure the buffer is ready...
Besides, Copy will return as much data as calculated, not the requested size.
And what city are you from, if not a secret?
By the way, are you sure you don't need to call any additional functions?
The library has both Refresh and BufferResize. It seems to me that they are necessary for normal functioning.
And where is it written that they should be?
I tried different variants.
I got no effect.
Continued....
The iIchimoku indicator is experiencing a glitch. My indicator just draws arrows depending on if(tenkan[i]>kijun[i]). As you can see in the screenshot the arrows are not drawn correctly
The full code is in the file Ich_1_f.mq5
However, if you calculate them manually, everything is displayed correctly
Full code in the file Ich_1_ok.mq5
Write the dll :
plug it in :
call :
we get this:
although both lines should return the same value 153.25.
Why?
Why?
Is this in the 32 or 64 bit version?
It is very simple - in the GetPtrVar(double a) function you take the address of a copy of the variable in the stack and then try to read the littered piece of stack memory.
The first time, because of a close call of GetValuePtr we managed to read from the uncontaminated stack, while subsequent function calls damaged the stack irrevocably.
There is no error.
It's very simple - in the GetPtrVar(double a) function take the address of a copy of the variable in the stack, and then try to read the littered piece of stack memory.
Yes, exactly, I felt that I needed to dig there somewhere.
you have to write in the dll
It is very simple - in the GetPtrVar(double a) function you take the address of a copy of the variable in the stack and then try to read the littered piece of stack memory.
The first time, because of a close call of GetValuePtr we managed to read from the uncontaminated stack, while subsequent function calls damaged the stack irrevocably.
There is no error.
I noticed it too. I think this is the right way to do it:
plugging :