New MetaTrader 4 Client Terminal 387 and MetaTrader 4 Data Center build 387 - page 10
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
This is not a visual mode bug. It is exactly zeroing the indicator buffers - reinitialising the buffers with the 388 version.
Alas, you are mistaken. It is a standard work of the mechanism called IndicatorCounted() - resetting of indicator buffers at significant changes of history (this mechanism was in all builds).
In this case, there is a bug in visual mode (I haven't found it in real mode during the week). I have already described what the bug is.
I've completely found the reason for this behaviour in the post below.
Thanks for checking, it's now clear where to dig.
We'll try to find it, fix it and release an update as soon as possible.
So there you have it - you're answering your own question
My mistake, IndicatorCounted() does not apply in recent developments. It just does in ZUP. And it does not catch this re-initialization.
I want to report that in the terminal and in the latest build there is a Bug, namely the iBands indicator when specifying the deviation parameter 0.8 puts 0. I understand that this parameter belongs to int and must be an integer. But when attaching the indicator to the chart the deviation value can be set less than 1. Why is it possible to set deviation less than 1 on the chart, but not in the Expert Advisor ...... or how to overcome this ..............
I want to let you know that in the terminal and in the latest build there is a Bug, namely the iBands indicator when specifying the deviation parameter 0.8 puts 0 . I understand that this parameter belongs to int and must be an integer. But when attaching the indicator to the chart the deviation value can be set less than 1. Why is it possible to set deviation less than 1 on the chart, but not in the Expert Advisor ...... or how to avoid it ..............
Yes. Look at the type of parameters passed.
it's int.
so use iCustom BBands
Yes. Look at the type of parameters passed.
it's int
so use iCustom BBands
and how to use it ?????
never used ....
and how to use it ?????
never used ....
The terminal obviously lacks a function like GetTerminalState which should return some code (a set of bits) that can be used to directly "ask" the terminal what it is doing now, for example IsConnected (which by the way does not always correctly return results after re-logins) only reports yes or no. but I would like a more detailed explanation:
- offline (trying to connect, not working, standing still)
- connecting (trying to connect)
- connected (connected to the server)
In the last case also need clarification:
- HistoryOrdersLoading, HistoryOrdersLoaded (downloaded, all history of orders is downloaded.)
- HistoryBarsLoading, HistoryBarsLoaded (downloaded, the entire history by prices.)
Also, during the order processing it is useful to know that a command to open an order has been sent and now the terminal is waiting for its opening, modification or closing. An order is never executed immediately and it would be good to know what the terminal is thinking about (ticks are ticking but the terminal is not trading for some reason - why?)
You may also "pack" the EA's operation/trading authorization status.
Good.
Putting it to visual testing. Moving Average Expert Advisor.
Setting the ZUP.
Euro. Hours.
Please note that my code tracks history swap. So, it re-initializes when history is swapping.
Earlier in this thread I posted a piece of code. All optimization is there.
I am pasting pictures here. My "bloated" code is intended for drawing pictures, that's all. It does not deal with auto-trading. If an image is drawn incorrectly, it is a bug.
First picture. A little story. One ray is drawn. Everything is normal.
Almost immediately after testing started several zigzag rays were drawn, a butterfly was drawn. Flying normal.
Flying further. YOUR re-initialisation has occurred. Software cannot track this. THERE IS NO ROUTINE WAY TO TRACE REINITIALIZATION.
Since calculation optimization is enabled, and there is no signal for full re-calculation, we see the result:
A bit of new history has accumulated. One zigzag ray has been drawn:
If we now reset the indicator, there will be an initial initialisation and everything will look like this:
And so on. There is no in-house capability to trace YOUR indicator buffer re-initialisation.
And you can't recalculate the indicator on every tick. Do such a mess yourself. YOU have a lot of things done in this spirit for a long time. And no matter how many times we've been telling you about many bugs, you haven't understood them. And now, when many programmers are just tired of fighting with you and have made their own workarounds of your bugs, you are beginning to arrange sneaky things.
Your code has grown just as big. And you have little idea of the consequences of your innovations.
Let's test it further.
Again your re-initialization has gone through several times. It should look like this:
Is it difficult to reproduce? Or maybe you just don't want to?
And further on in testing everything is in the same vein.
Don't blame it on others. The code is bloated.
-------
In conclusion, I'll say it again. I'm not worried about myself. I may bypass any of your bugs programmatically for me. But users - and there are a lot of them - won't be able to.
I will add. I've never sold any of my indicators and haven't developed any of my indicators for a fee. I think that when metaquotes can change everything fundamentally like in 387-388 builds, no one from the outside will be able to build a good business on development using MQL(*) languages. You can't offer third party developers a stable development framework yet.
All paid developments using your languages are considered a kind of dodge.
Did everything as described. But with a few modifications.
Here's the log.
After the last butterfly deletion (two triangle deleted lines) there was no buffer re-initialisation!
By the way, the same behaviour is reproduced in your favourite 225 build