New MetaTrader 4 Client Terminal 387 and MetaTrader 4 Data Center build 387 - page 8
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
So you think it's OK?
If so, who needs it, the 387-388 build?
A lot of people are still working on 225. People need stability.
When starting the optimisation of this EA, MT4 gives a message that there is not enough RAM on this computer (6GB oo) and starts the optimisation. The "Start" button remains active instead of "Stop". Overall, it's clearly a glitch. Previous build did not suffer from such a nonsense.
It's not a bug report, so there's no reaction.
:)))
(c) "Do you see a gopher? No! Neither do I. But you do!"
In 387-388 builds, re-initialisation of custom indicator buffers happens at unpredictable times. This is not good.
If the re-initialization is so necessary, the solution may be the following.
We introduce an additional function in mql4 that can prohibit such reinitialization or allow it.
We introduce a boolean function, which returns TRUE if the terminal reinitializes it, otherwise it returns FALSE. The second function is valid if the first function permits reinitialisation.
In this way all problems are solved. Whoever needs it allows automatic reinitialization by the first function. At the same time it can control the times of reinitialization by means of the second function.
It is possible to combine all this in one function. It is at developers' discretion.
And everybody is satisfied. The errors are eliminated. And third-party programmers - custom programmers - are insured against surprises.
It is a beautiful solution.
When starting the optimisation of this EA, MT4 gives a message that there is not enough RAM on this computer (6GB oo) and starts the optimisation. The "Start" button remains active instead of "Stop". Overall, it's clearly a glitch. The previous build didn't suffer from such a bug.
Unfortunately, you haven't specified any initial data, test parameters or logs.
In addition, you are referring to the libraries (DLL), which not only require a lot of installations, but they do not work because of missing additional libraries (this is the author of libraries, who forgot about additional DLL files).
Contact the author of these libraries for information.
In 387-388 builds, re-initialisation of custom indicator buffers happens at unpredictable times. This is not good.
Apparently, you do not want to check your bloated code, but are trying to shift the problem onto us. Your rhetoric is absolutely transparent - "it's not my problem".
I don't care. I don't have a problem. I can redo it to make it work properly. But I can't redo all the indicators that other people use.
You are also replacing the meaning of "strong history changes result in the need for a complete recalculation" with "unpredictable moments". They are predictable - the history has changed, which necessitated a complete re-initialisation. If your code doesn't want to be aware of this situation and doesn't want to recalculate itself, then you are engaging in self-delusion.
Demonstrate with a full breakdown the problem. Not in words, but on clear settings, code, logs, clear screenshots etc.
As a programmer, it is wise to have technically backed, clearly described step by step discussions. Piecemeal links and scattered, unassembled messages do not constitute a bug report.
The quality of a report is determined by the reproducibility of its problem by outside users. As far as I understand, so far no one (including the developers) in this thread has been able to reproduce your problem.
Renat.
I was wondering if you can hope to get the custom indicators back to rendering after a test in the tester. I have disabled LiveUpdate on some terminals for the time being. You see, for us - the creators of Forex trading "movies" - it is not enough to read or write scripts and watch the film without images, but only with sound. We need to see what we have done there, and how well.
There have even been thoughts that the developers disabled the rendering in MT4 out of spite that MT5 is not progressing well. If so, maybe it turns out that traders and brokers need one thing and you are trying to impose another. Maybe then you'd better change your position in that sense.
And if it is caused by hasty technical decisions, which have caused such harm to developers of experts, then you, as programmers, should have the flag in your hands to make everything good.
So can we hope for a speedy solution to this issue?
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 starting 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 has grown.
-------
In conclusion, I'll say it again. It's not me I'm worried about. I can programmatically bypass any of your bugs for myself. But I will not be able to do it with a huge number of users.
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.
And all paid developments using your languages at the moment I consider as some kind of scam.
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 branch 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 zig-zag 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 has grown.
-------
In conclusion, I'll say it again. It's not me I'm worried about. I can programmatically bypass any of your bugs for myself. But I will not be able to do it with a huge number of users.
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.
And all paid developments using your languages at the moment I think it is some kind of a scam.
OK. Ok, once again let's put all emotions to rest and calmly deal with the situation.
What is given - visual testing. Let us run visual testing and apply the same indicator for logging. After all these test runs we get a sad picture.
Something has gone wrong exactly in the visual testing mode - there are records with Bars equal to 2648 instead of the expected 130, but 130 again at the next tick/bars.
That's the whole reason, and full re-initialisation has absolutely nothing to do with it, especially on every tick.
Scared of the eyes and the hands do the work. Exactly 10 minutes to find and describe the bug.