Errors, bugs, questions - page 492
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
Absolutely, exactly on all of them.
As much as was available, so much was received. That's the way to understand it. Check the available depth of history. Make sure the data is available before requesting it. What build do you have? recently corrected a bug with copying monthly timeframes, this might be it.
So it is not checked well or the Expert Advisor is NOT multi-currency, it just may work on different symbols. The reasoning is simple - knowing that the ticks come to different symbols at different times. Accordingly, if an EA is onTick EURUSD (for example), and it checks GBPUSD or even just tick changes of GBPUSD instead of EURUSD, the result will be different. In particular, a bar formed on EURUSD may occur before the formation of a bar with the same time on GBPUSD. If you trade GBPUSD twice on the same bar: the previous GBPUSD bar will still be considered as a new bar (zero). As for the multi-currency indicators, everything is clear. Learn the basics.
What the fuck is the math, a tick has come in on 1 pair, but if the second tick is late and f...
i.e. we need the price at the moment of a new bar appearance and the ticks
It does not play a role in the occurrence of a new bar at all symbols, but it is from
The strategy depends, if you are not a scalper
I would like to ask the MQ team once again if there are plans to bring the iCustom() function to a working state.
At present, the Expert Advisor developers cannot offer a universal solution using iCustom(),
where the customer could specify the name of an external indicator used by the Expert Advisor.
For this purpose, the customer needs to have the Expert Advisor source code, as well as to manually enter each indicator name in the Expert Advisor's code, which is quite inconvenient, to put it mildly.
There is also the problem of mandatory explicit indication of the values of the indicator buffer cells.
If no value (empty or nonempty) is explicitly assigned to the indicator buffer cells in the indicator text, the iCustom() function may fill the indicated cells in the Expert Advisor with
with any rubbish. I think that such operation of the function cannot be considered correct.
I would like to ask the MQ team once again if there are plans to bring the iCustom() function to a working state.
At present, the Expert Advisor developers cannot offer a universal solution using iCustom(),
where the customer could specify the name of an external indicator used by the Expert Advisor.
To do this, the customer needs to have the Expert Advisor source code, as well as to manually enter each indicator name in the Expert Advisor's code, which is quite inconvenient, to put it mildly.
You can pass a dynamic name of the called indicator in iCustom, but the set of parameters of each custom indicator is different.
Unfortunately, we do not know a universal solution to the question "how can we safely implement the call without touching the code without knowing what and with what parameters it will be called?
If I understand correctly, you want to make a plugin system, when a third-party user sets any name of the indicator with parameters (for example, "MyIndicator(10,20,50,100)") in the EA settings. For such a case with a rigid format of the name, you can parse the string yourself, form a block of parameters and implement a dynamic call of iCustom with a different set of parameters as a wrapper class. In other words, several variants of iCustom call with different sets/number of parameters will be hidden inside.
There is also a problem of a mandatory explicit indication of the value of the indicator buffer cells.
If no value (empty or nonempty) is explicitly assigned to the indicator buffer cell in the indicator text, the iCustom() function may fill the indicated cells in the Expert Advisor with
with any rubbish. I think that such operation of the function cannot be considered correct.
It is impudence and downright laziness of the developer not to fill the buffer he was given at his complete disposal.
The runtime system doesn't know how you use the indicator buffer and has no right to fill it with some values, especially during the moments of mass over allocations (paging or chart updates). The indicator is necessarily notified about all cases when recalculate is needed through the OnCalculate(...,const int prev_calculated,...) function and parameter prev_calculated.
In iCustom, you can pass a dynamic name of the indicator to be called, but each custom indicator has its own set of parameters.
Unfortunately, we don't know a universal solution of the question "How can we safely implement the call without disturbing the code, not knowing what and with what parameters it will be called?
If I understand correctly, you want to make a plugin system, when a third-party user sets any name of the indicator with parameters (for example, "MyIndicator(10,20,50,100)") in the EA settings. For such a case with a rigid format of the name, you can parse the string yourself, form a block of parameters and implement a dynamic call of iCustom with a different set of parameters as a wrapper class. In other words, several variants of iCustom call with different sets/number of parameters will be hidden inside.
By the problematic necessity to change the code, I meant the requirement to explicitly specify the indicator name during testing
in the format #property tester_indicator "Name.ex5", but not a different number of parameters of the indicator.
Indicators can be used with the default parameters, by selecting only the number of indicator buffer with the corresponding signal.
This is impudence and sheer laziness of the developer not to fill in the buffer that he was given at his complete disposal.
The runtime system doesn't know how you use the indicator buffer and has no right to fill it with some values, especially during the moments of mass over allocations (paging or chart updates). The indicator is necessarily notified about all cases of necessity of recalculate via the OnCalculate(...,const int prev_calculated,...) function and parameter prev_calculated.
Is it really hard to assign Empty_Value to unused cells in iCustom() instead of clogging them with rubbish from the stack?
https://www.mql5.com/ru/forum/1111/72233#comment_72233
Note that the actual value of the buffer cells remains an Empty. It is iCustom() that does the tampering.
By problematic necessity of changes in the code, I meant the requirement to explicitly specify the indicator name during testing
in the format #property tester_indicator "Name.ex5", but not a different number of parameters of the indicator.
We will solve the issue further - there are nuances.
Is it really difficult to assign Empty_Value to unused cells in iCustom() instead of filling them with rubbish from the stack?
https://www.mql5.com/ru/forum/1111/72233#comment_72233
This should not be done. Read my answer again, please.
The reason why iCustom() assigns arbitrary values to those buffer cells that are not actually filled with anything is unclear to me, as well as why it cannot be avoided in any way.
I suppose it has something to do with allocation of memory for the corresponding array of indicator buffer data.
Such an operation of iCustom(), when it is impossible to determine the origin and truth of the data, seems inadmissible to me and creates additional risks for the user.
If iCustom() assigns arbitrary, inconsistent with the real values to the buffer cells anyway,
why doesn't it assign values equal to Empty_Value to these cells as it is implemented in MT4?
Then at least their status would be clear.
but this way
there is a rounding off, does it still say that?
I don't argue.
but this way
there is rounding still writes, should it be like that?