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
The executionresults show that the compiler acts contrary to logic:
For a pure constant string, the size of the buffer by StringBufferlen=0, which means that the string is constant:
Re-assigning a "supposedly" constant string is not working with a constant, but rather creating exactly a dynamic variable with a preallocation of 260 characters:
For a pure constant string, the buffer size by StringBufferlen=0, which means that the string is constant:
Reallocating a "supposedly" constant string is not working with a constant, it's creating a dynamic variable with a preallocation of 260 characters:
it's time to introduce allocators )))
As a reminder, there is a bug with the string buffer:
The function from the DLL can be anything.I suggest adding an extended version ofStringToTime function to MQL in the form:
Because in the current version the function always returns valid time, even if the string contains rubbish, and the current date is returned, which is particularly strange:
StringToTime("aaabbbccc") returns "2019.09.05 01:00:00" Is this normal? In this implementation, the function is dangerous for health at all. Therefore, a version with correctness checks is needed.
So far we have to parse with our own function,but the problem is that the time can be specified in different formats.And I don't really want to code all those formats re-inventing the wheel when the time has already been implemented in MQL.
Basically, this also applies to other string conversion functions : StringToInteger, StringToDouble. No validity check is provided for them too.
p.s. Hmm, it turns out thatGetLastError() generates errors in these cases. I didn't know that. The documentation for these functions doesn't say anything like that. That removes the problem, although it would be easier with a bool.I support Alexey's suggestion, safe handling of strings is key to avoiding hidden errors.
error "property already exists with different value and will be skipped".
Used it for the first time. No other files have it. Does not depend on value. Build 2136.
Please bring back the old style styler.
Now I can't figure out what's supposed to run here:
This piece used to look like this:
error "property already exists with different value and will be skipped".
Used it for the first time. No other files have it. Does not depend on value. Build 2136.
This error occurs while working with projects if the value of the property specified in the source code conflicts with the value in the project settings.
Project Properties
Please bring back the old style styler.
Now I can't figure out what's supposed to run here:
This piece used to look like this:
Multiple nested ifs can't be saved by any alignment. We need to change the code to make it readable.
Multiple nested ifs cannot be saved by any alignment. You have to change the code to make it readable.
There is no multiple nesting - top level is if, then if else.
I'm asking for the old style back when if else looked like this:
- Was on a single line and there was no offset of the subsequent text to the right.
Here's an example from theConditional if-else statement help ( the old styler)
and this is what the new styler does: