Errors, bugs, questions - page 2342
![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
Are the resources limited to this size?
So it makes all the more sense to condense the data being transmitted.
In that sense MT4 was much wiser than MT5 - there was no program crash and you could analyse the LastError.
Firstly: continuing to execute the program after an unrecoverable critical error is not wisdom, but stupidity.
Secondly: I haven't got to PrintError() in MetaTrader 4 765x32 after running it
Third: If you remove strict, it has reached it, but GetLastError() returns 0, so it is unclear what to analyze
How to notify the user about stopping the EA?
In this sense MT4 was much wiser than MT5 - there was no program crash and you could analyse the LastError.
And when accessing an array, isn't it logical to check the access index?
Firstly: it is stupidity, not wisdom, to continue executing the program after an unrecoverable critical error occurs.
Secondly, after you execute this in MetaTrader 4 765x32, PrintError() never happened.
Third, if you remove strict, it will return 0, but GetLastError(), so it is not clear what to analyze.
The task was not to show that MT4 is better than MT5. I had to solve a practical problem.
Forum on trading, automated trading systems and strategy testing
Libraries: HistoryTicks
fxsaber, 2018.12.10 13:55
Get a message that the EA has stopped due to an array out of range(not the EA author's fault). For example, due to lack of memory or other failure. It means that you will know right away that the EA has stopped abnormally, rather than accidentally notice it a few hours later.
It is unpleasant when the Expert Advisor has stopped, but it is not reported in any way.
And when accessing an array, wouldn't it be logical to check the access index?
It is not logical.
So it is all the more reasonable to condense the data being transmitted.
Checked, 60Mb is easily written (MT4/5) to Resources. So if there is a limit, it is higher.
A small point, but still.
When sending to the Storage - the first panel "Fixing" - works fine, and the second, confirmation, in my first case, does not wait for the OK key, but immediately goes out, and secondly - it does not show all the files sent. I checked it though - the files are sent normally.
Is it just me ?
It seems to be correct - when after sending a list of sent files is displayed with a confirmation that all went well.
Doesn't make sense.
And why?
It seems to me that you don't have to check the index where, logically speaking, there is no way an index that goes beyond the array's limits can appear. And even in this case you should use ASSERT, just in case.
And in those places where the index depends on previous actions related to external parameters, quotes and user's actions, the check for index reference should be obligatory.
In your opinion, it is not so?
And why?
It seems to me that there is no need to check the index where, based on the logic of the program - there is no way an index can appear outside the array.
I agree.
And even in this case you will have to use ASSERT just in case.
I disagree since code readability will suffer much.
In those places where the index depends on previous actions concerning external parameters, quotes and user actions, the check for the handling index must be obligatory.
I don't understand what we mean here by external parameters. Every time you check that ArrayResize or ArrayCopy have completed normally and not trivial memory running out, it will bloat the code through ASSERT, and this is really a mess. If you don't check it, you'll get an unnoticeable stoppage of the Expert Advisor. So far, I have found only one solution - to replace ArrayResize and ArrayCopy.
Who is in the way?
ChartSaveTemplate(chart_id,"\\Files\\MyPreferredTemplates\\cewl.tpl");
The function does not create a folder, it only writes a template if a folder already exists .... If the folder does not exist, error 4112
So, folders must be prepared beforehand...
It's interesting, the FileOpen function can't create a folder in the template folder and the ChartSaveTemplate function doesn't create directories...
That is, if you want to save templates in subfolders, then create folders manually....
out of memory
when searching for GlobalVariables
can arise?