Questions from a "dummy" - page 176

[Yedelkin]

Karlson:

3Б. Closing partially by opening a half sell - OUT.

Too bad :/ It turns out that there can be several trades in the history with the OUT property, while the position will still exist.

[Anatoli Kazharski]

Yedelkin:
Bad :/

Why bad? It's simple, if I understand you correctly. If OUT and there is a position, then there was a reduction in volume. If OUT and no position, then the position was closed completely.

[Yedelkin]

tol64:
Why is it bad? Everything is simple, if I understood you correctly. If there is a position and OUT, there was a decrease in volume. If OUT and there is no position, then the position was closed completely.

The bad thing is this. Your approach"If OUT and there is a position, there has been a reduction in volume. If there is no OUT and there is no position, then the position has been closed completely" has one feature that I find cumbersome, namely, the need to additionally check the existence of information about the position in the terminal database each time.

We all know that information in the base terminal gets with a certain lag in relation to the actual situation. Therefore we cannot exclude situations when the check result is"there is a position and it is OUT", but in fact the position has been fully closed. In other words, it is possible to obtain inaccurate information and use it as the basis for taking wrong actions. Or one will have to invent additional checks, delays, or whatever is convenient.

But you can do without all of these tricks. In particular, without checking for position availability. To do this, it is sufficient to leave a one-to-one correspondence between position closing and DEAL_ENTRY_OUT property (correspondence - as it is presented now in Handbook), and allocate reduction of position volume into a separate property of transaction. Then it will be enough to find in the history (HistorySelectByPosition) a single deal with property DEAL_ENTRY_OUT, and be assured that the position is not reduced, but exactly closed, and that under no circumstances can it be reversed.

[Anatoli Kazharski]

Yedelkin:

The bad thing is this. Your approach"If OUT and there is a position, there has been a reduction in volume. If there is no OUT and there is no position, then the position has been closed completely" has one feature that I find cumbersome, namely, the need to additionally check the information about the position in the terminal database each time.

We all know that information in the base terminal gets with a certain lag in relation to the actual situation. Therefore we cannot exclude situations when the check result is"there is a position and it is OUT", but in fact the position has been fully closed. In other words, it is possible to obtain inaccurate information and use it as the basis for taking wrong actions. Or one will have to invent additional checks, delays, or whatever is convenient.

But you can do without all of these tricks. In particular, without checking for position availability. To do this, it is sufficient to leave a one-to-one correspondence between position closing and DEAL_ENTRY_OUT property (correspondence - as it is presented now in Handbook), and allocate reduction of position volume into a separate property of transaction. Then it will be enough to find in the history (HistorySelectByPosition) a single deal with property DEAL_ENTRY_OUT and know for sure that the position is not reduced, but exactly closed, and that under no circumstances it cannot be reversed.

In OnTrade(), we receive the response from the server. That is, if we check the event in OnTrade(), we will already know for sure if there is a position or not. Although we can provide standard options such as DEAL_ENTRY_FULLOUT (complete closing) orDEAL_ENTRY_PARTOUT (partial closing) to make everything perfectly elegant.)))

In the meantime, you can make separate functions, so that you don't have to introduce "cumbersome checks" every time.

[Yedelkin]

tol64:

Although you could make standard options like DEAL_ENTRY_FULLOUT orDEAL_ENTRY_PARTOUT to make everything perfectly elegant.)))

That's what it's all about. We won't even need to make additional checks in OnTrade which will look too cumbersome comparing to the proposed solution (FULLOUT / PARTOUT).

[Anatoli Kazharski]

Yedelkin:
That's the point... You wouldn't even have to do extra checks in OnTrade, which would still look cumbersome compared to the proposed solution (FULLOUT / PARTOUT).

Try to make a proposal to Service Desk. Maybe they will consider it and one day implement it.

[Yedelkin]

tol64:
Try to make a proposal to the Service Desk. Maybe they will consider it and one day implement it.

I already did :) As a language error ...Wow, it took me an hour to compose.

[Anatoli Kazharski]

Yedelkin:
I already did :) As a slip of the tongue... Wow, it took me an hour to compose.

It still can't be called a mistake. But what can you do now that you've already been sent. ))

[Yedelkin]

tol64:
It still can't be called a mistake. But what can you do now that you've been sent. ))

Well, this is where the evaluation categories come into play a little bit :) I tried to justify the Errors category :)

[Валерий]

Yedelkin:

Yes, each period corresponds to a certain value. Someone posted it on the forum a couple of years ago. You can find out for yourself by running a line like the one below:

The script will print the ENUM_TIMEFRAMES values for all periods in decimal system:

void OnStart()
  {
//---
   for(int i=(int)PERIOD_CURRENT;i<=(int)PERIOD_MN1;i++)
     {
       ResetLastError();
       string period=EnumToString((ENUM_TIMEFRAMES)i);
       if(GetLastError())
        continue;
       Print(EnumToString((ENUM_TIMEFRAMES)i)+"="+IntegerToString(i));
     }
  }
//+------------------------------------------------------------------+