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
Please bring back the old METAQUOTES style or at least make sure that the codes written on one line are not formatted.
Example:
Please revert to the old METAQUOTES style or at least make sure that the codes written in one line are not formatted.
use the Pico style, it's very similar to what you're looking for
but the Pico style splits the if - else statement on two lines if you use { }
Your code where using { }
if not using { }
2133 Here's a gimmick like this
use the Pico style, it's very similar to what you're looking for
but the Pico style splits the if - else statement into 2 lines if you use { }
Your code where using { }
if not using { }
Yes !!! did a full analysis of the available styles and chose PICO and RATLIFF
PICO is the most compact.
RATLIFF is the smartest.
But it is absurd for METAQUOTES to change a style that has been used for years. It would disrupt the lives of all users. An irresponsible change. A few months ago I messed up something about their style, I thought it was wrong to move despite the small changes, but now they have messed up.
2133 uma piada
Yes !!! we know it's a beta version, but if something was correct in the old versions and has now changed in the beta version, it's probably with these changes. Better complain now to make sure everything is going right
The documentation is obsolete in this case.
For the sake of efficiency, strings are now preallocated larger than requested, as in the vast majority of cases they are ramped up by subsequent operations.
This is now clear.
But no matter how I change the string length, the StringBufferLen result always stays 260.
The documentation is out of date in this case.
For the sake of efficiency, the strings are now preallocated larger than requested, since in the vast majority of cases they are incremented by subsequent operations.
Is it possible in this case
s2 can increase in the future?
Result: 260
Expected: 100 or 0.
I added StringLen to the test, and initialized the string differently.
In documentation it is one thing, but in fact it behaves differently.
And buffer in this case shows 0 instead of 260.
So, either there is a problem with string initialization. Or StringBufferLen is failing.