Errors, bugs, questions - page 2591
![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
What happens if the copied string is bigger or smaller than the allocated buffer size?
If it's smaller it's OK, as a rule, the string buffer is always slightly larger than the string itself (but that's not a fact!)
But if you write more than that, it's almost guaranteed that the terminal will crash.
And crash most likely will not happen immediately, but only at next work with dynamic memory (reallocation of arrays or string buffers) or at shutdown, when used MQL program memory is returned to the system
1. in MQL only Unicode, that's why the character size is 2 bytes
2. string is a structure (4 bytes buffer size and 8 bytes pointer size)
Copying to string should be
If it does not work, the error must be found elsewhere
Yes, the simplest function
and causes a problem. The line is copied evenly, but there are big skips. That is, there is a delay in copying.
That's why other functions have been tried, which also cause the problem if used correctly.
All sorts of mutex, recursive_mutex, lock_guard do not solve the skipping problem.
Because of this I don't know what to think anymore, the string from the socket comes correctly,
received string type wchar_t* automatically means, that it is Unicode-encoded, and each character in string is equal to 2 bytes (tested).
But somehow I don't get that wchar_t* pointer will copy correctly eight bytes into string twelve bytes.
Maybe it is the bit mode of OS that influences it somehow? Everything is checked on 64-bit versions, Windows and Linux.
I don't understand, what are the gaps? Blank lines?
Do you write from all threads to the same MQL line or to different ones?
When in MQL code do you decide that there is data in the string and it can be processed/output ?
If everything is in one line, which is wrong, then you need a critical section on the DLL side, which is accessible from MQL and the line change counter
Pseudo code from MQL
DLL
This is an example scheme and there will be skipping of lines from MQL side (not all lines will get to MQL, some of them will be overwritten)
I don't understand, what are the gaps? Blank lines?
Do you write from all threads to the same MQL line or to different ones?
When in MQL code do you decide that there is data in the string and it can be processed/output ?
If everything is in one line, which is wrong, then you need a critical section on the DLL side, which is accessible from MQL and the line change counter
Pseudo code from MQL
DLL
This is an example scheme and there will be skipping of lines from MQL side (not all lines will get to MQL, some of them will be overwritten)
Yes empty lines, you can see it on the screenshot.
Yes from all threads to one MQL line. Since creating variables for the string on the fly is also a problem.
If we don't know beforehand how many sources will be involved where the strings come from, in other words, dynamically.
I was also thinking about critical sections and I also thought that MQL should block some way to read. Thanks for the example, I will think it over.
But it turns out that you still recommend to get each string source in its own separate variable? And not in one variable of MQL.
It's just that it's more convenient to work with received data from all the threads from one string variable.
I thought that if there is a write lock on the dll side, in MQL reading does not require a lock, i.e. it's as if MQL takes into account such a copying implementation.
But even if I get a string from one thread, I still get skips!
If I use other copying functions with correct parameters, I will not get skips, no matter whether it is one or several threads, but I will still get an uneven string of characters.
If you use wrong parameters, the string is even, but it starts leaking.
If less is OK, usually the string buffer is always slightly larger than the string itself (but this is not a fact!)
But if you write more, a terminal crash is almost certainly guaranteed.
And crash most likely will not happen immediately, but only at next dynamic memory operation (redistributing arrays or string buffers) or at shutdown, when used memory of MQL programs is returned to the system
Then why do you advise a newcomer to usewcscpy function?
There are safer functions: wcscpy_s, wmemcpy_s.
Please explain why in the OnCalculate handler the time of each newly formed bar time[0] is ahead of the tick time that we request using the SymbolInfoTick function? TheSymbolInfoTick function should always return the last known tick.
I am attaching an indicator which reproduces this problem in the tester in sweat mode.
At each bar boundary there is this problem.
PS. And according to the documentation, that OnCalculate is called for all ticks without omission, the tick volume should always coincide with ticks counter, but it's not always true.Please explain why in the OnCalculate handler the time of each newly formed bar time[0] is ahead of the tick time we are requesting with SymbolInfoTick function? The SymbolInfoTick function should always return the last known tick.
I am attaching an indicator which reproduces this problem in the tester in sweat mode.
On each bar boundary there is this problem.
PS. Also this indicator demonstrates another problem: there is tick counting, and judging by the statement in the documentation that OnCalculate is called for all ticks without missing, the tick volume should always coincide with the tick counter, but this is not always the case.Please give me the build number.
Please give me the build number
2093
2093
The problem you described has been fixed in build 2155
Found the highlighted constant SYMBOL_CHART_MODE_OLD in the editor.
Of course it is not in ENUM_SYMBOL_CHART_MODE.
What is it?