Bug only with reading. There is no way to read it.
Yeah. I got that already. Too bad. Do you think MQ will bother with that? I doubt it, though.
It is a pity, of course, we will have to give up the idea of rewriting some codes from MT5 to MT4. Still, the main crowd is still on 4K. A mystery of nature...
I think you just haven't read the canvas before, you've only made entries there.
I remembered now that I could not understand a couple of years ago why code worked on 5 and not on 4. Now I understand that the reason for it was because the code did not work when reading from the resource.
To know from the history what was the size of the position at the time of making a deal, we need to run by PositionID each time, calculating the lot. Or, you need to create some caching for it to work without lags.
If you have made a hundred flips, you will have to run in the loop this hundred times each time, with corresponding non-fast HistorySelectByPosition.
If I understand correctly, then there is no other method for determining this value.
Or, for example, you make a lot of DEAL_ENTRY_IN and DEAL_ENTRY_OUT, without closing a position. And it is possible to determine the volume of historical position, again, only by appropriate jogging on the history.
Is it possible to enter DEAL_POSITION_VOLUME - size of position after a trade?
I don't know if I'm writing in the right place, but in my signal, which serves to monitor the performance of the EA, a warning has appeared which has absolutely nothing to do with reality.
""80% of the gains have been made in 16 days. That's 4% of the signal's total lifetime of 376 days.""
How can this be, or am I misunderstanding something?
int f( int x )
{
while ( true ) {
/* ...*//*if ...*/continue;
/*if ...*/return1;
/*if ...*/continue;
/* ...*/
}
} //Error: '}' - not all control paths return a value
If it wasn't serious, the Developers here and here ... wouldn't be fixing it. Believe me, they are not fools and can tell the difference between serious
Graphic objects do not have a property that defines their overlay order (Z-Order). The existing property OBJPROP_ZORDER has nothing to do with it, although it has a similar name for some reason.
I used to think that the overlay order was determined by the creation date of an object. However, if for any object you do
then this object is placed on top of the others. No properties of this object are changed. Accordingly, it is impossible to determine programmatically which object is above or below. However, MT stores this information somewhere. Therefore, I would like to have a corresponding property in ObjectGetInteger.
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.
Yes, installed on another terminal - works in release too.
Bug only with reading. No way to read.
Bug only with reading. There is no way to read it.
Yeah. I got that already. Too bad.
Do you think MQ will bother with that?
I doubt it, though.
It is a pity, of course, we will have to give up the idea of rewriting some codes from MT5 to MT4. Still, the main crowd is still on 4K. A mystery of nature...
I think you just haven't read the canvas before, you've only made entries there.
I remembered now that I could not understand a couple of years ago why code worked on 5 and not on 4. Now I understand that the reason for it was because the code did not work when reading from the resource.
Let's imagine a reverse TS on netting. All deals will beof DEAL_ENTRY_INOUT type.
To know from the history what was the size of the position at the time of making a deal, we need to run by PositionID each time, calculating the lot. Or, you need to create some caching for it to work without lags.
If you have made a hundred flips, you will have to run in the loop this hundred times each time, with corresponding non-fast HistorySelectByPosition.
If I understand correctly, then there is no other method for determining this value.
Or, for example, you make a lot of DEAL_ENTRY_IN and DEAL_ENTRY_OUT, without closing a position. And it is possible to determine the volume of historical position, again, only by appropriate jogging on the history.
Is it possible to enter DEAL_POSITION_VOLUME - size of position after a trade?
I don't know if I'm writing in the right place, but in my signal, which serves to monitor the performance of the EA, a warning has appeared which has absolutely nothing to do with reality.
""80% of the gains have been made in 16 days. That's 4% of the signal's total lifetime of 376 days.""
How can this be, or am I misunderstanding something?
An error in the logic of the operators
This is not serious.
This is not serious.
Graphic objects do not have a property that defines their overlay order (Z-Order). The existing property OBJPROP_ZORDER has nothing to do with it, although it has a similar name for some reason.
I used to think that the overlay order was determined by the creation date of an object. However, if for any object you do
then this object is placed on top of the others. No properties of this object are changed. Accordingly, it is impossible to determine programmatically which object is above or below. However, MT stores this information somewhere. Therefore, I would like to have a corresponding property in ObjectGetInteger.