Please bring back the old METAQUOTES style or at least make sure that the codes written on one line are not formatted.
Example:
Старая модель и я считаю ее идеальной моделью для однострочных кодов.
if(TakeProfit>0){btp=Ask+(TakeProfit*Point());}else{btp=0;}
if(StopLoss>0){bsl=Ask-(StopLoss*Point());}else{bsl=0;}
Новый стиль, который портит всех моих роботов.
if(TakeProfit>0)
{
btp=Ask+(TakeProfit*Point());
}
else
{
btp=0;
}
if(StopLoss>0)
{
bsl=Ask-(StopLoss*Point());
}
else
{
bsl=0;
}
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.
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
There are two suggestions that I would like METAQUOTES to adopt.
1) Put a lock on the graph to prevent the used graph from closing along with unnecessary graphs when using CTRL-F4.
2) Allow the user to define the number of cores to use on the cloud network. For example: I could limit use to 50 cores in CLOUD NETWORK just to help and increase optimization speed along with the 100 cores I already have on my servers. This way I would not have to buy one or two more servers.
Currently, I cannot use CLOUD NETWORK because it makes my servers useless and the value of the optimization becomes high.
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.
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.
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.
Allow the use of cookies to log in to the MQL5.com website.
Please enable the necessary setting in your browser, otherwise you will not be able to log in.
You are signed in. Two-factor authentication has been disabled. Set it up again and scan a new QR code, or continue with two-factor authentication disabled.
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.