Custom symbols. Errors, bugs, questions, suggestions. - page 12
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
Bug 16.
Previously, CustomTicksAdd generated bars from ticks that referred to the current day. This is not the case now either.
This bug seems to be related to bug #14.
The removal of the symbol from the market overview is possible for the following reason. Calling consecutively CustomSymbolCreate - CustomSymbolDelete - CustomSymbolCreate with the same custom symbol name was causing the symbol ID to be hit. Therefore, when checking whether a symbol can be removed from the market overview, the graph of this symbol was not found (the identifier is corrupted), and the symbol was safely removed. This has been fixed.
When applying a tick to a chart, the same thing is possible - searching for the chart by the symbol identifier did not give a result
Bug 15.
We run the following indicator on the symbol of this EA (with ChartSetSymbolPeriod-row removed)
It produces only zeros.
Fair enough.
Calling CustomRatesUpdate resets all change counters and recalculates indicators from zero
Quite rightly so.
When you call CustomRatesUpdate, all change counters are reset and indicators are recalculated from zero
What is the logic behind this solution? After all, there are unchanged bars on the left.
What is the logic behind this solution? After all, there are invariant bars on the left.
prev_calculated contains a value that was returned on previous OnCalculate call
Indicator can return any value based on its own logic. Therefore, there is no sense to run through all indicators and change the value of prev_calculated to its own calculated value taking into account the timeframe. And it is resource-intensive, may even be unreasonably resource-intensive.
It's much more honest to set it to 0, as in the beginning, when nothing was counted yet
prev_calculated contains the value that was returned on the previous call to OnCalculate
Indicator writer can return any value based on its own logic. Therefore, there is no sense to run through all indicators and change the value of prev_calculated to its own calculated value taking into account the timeframe. And it is resource-intensive, may even be unreasonably resource-intensive.
It's much more honest to set it to 0, as in the beginning, when nothing was counted yet
Then what to do, when indicators on a custom symbol after each tick rollover are completely recalculated because of this zero value?
Indicators are specially written not to slow down the Terminal, and here it starts the opposite.
Then what about when, on a custom symbol, after each tick rollover, the indicators are completely recalculated because of this zero value?
This shouldn't be the case. Check
It shouldn't be like that. Check
Let me clarify that it's not only CustomTicksAdd, but also RatesUpdate, which is a tick-through from the past. In fact, even the working TicksAdd did not form the bars earlier than the current day. We have to form them by ourselves. And we get zero prev_calculated because of it.
To clarify, it is not only CustomTicksAdd, but also RatesUpdate, which is a tick-through from the past. In fact, even the working TicksAdd did not form the bars earlier than the current day. We have to form them by ourselves. And we get zero prev_calculated because of it.
Anyway, when replacing, refreshing or deleting bars, all indicators will be recalculated from zero. This is out of question.
The addition of ticks should work as usual, i.e. ticks are fresh, current ticks, but not ticks from yesterday/the day before.
I have run your Expert Advisor from bug 11 description and then run the indicator with a print on each OnCalculate
Here are the logs.
It means that everything is working correctly in a normal situation (ticks are today, as they should always be). The ticks are added, and the indicator is considered sparingly
In any case, when replacing, updating, deleting bars, all indicators will be recalculated from scratch. This is out of the question.
Adding ticks should work as usual, i.e. the ticks are fresh, today's ticks, not yesterday's - the day before yesterday's.
Run your Expert Advisor from bug 11 description, then run the indicator with the print on each OnCalculate
Here are the logs.
It means that everything is working properly in a normal situation (ticks are of today, as they should always be). The ticks are added, and the indicator is considered sparingly
Is this a correct statement?
Moreover, if it is 00:00:01, we cannot use CustomTicksAdd to reshape a bar that was only two seconds ago.
Is this a correct statement?
For the tester, the tick of the day before yesterday is fresh, today's tick of the day before yesterday.
I see your point. Your exercise with custom tics from six months ago is of a distinctly tester nature. Your situation is not normal (in the sense of normal practice)