Questions from a "dummy" - page 13

[[Deleted]]

stringo:

Actually, there is as much as 8 bytes of information given to the message, which can be interpreted as desired. It can be datetime, double, 4 short, 8 char, or 64 bits bit by bit.

With fours, 4 bytes of magic was enough to encode anything, but now we have 8. All you need is a wish.

I know, I used it quite well in 4, and I read the article (I liked the idea a lot).

Here's not clear just - Why different types are specified in different places?

[Cron]

Please advise how you can close a position with TP and SL, if the price is close to the TP and you need to exit now.

I send an order to open a new position of equal volume. In most cases it works. But sometimes I have a situation where a position has time to close by TP and instead of closing, I get a new position in the market... :(

How do I indicate that the position opened refers to the closure of an existing position, and if the main position has already been closed, not to open a new one?

I can think of options like "remove SL and TP before the close or wait for the TP to close", but they are not nice solutions. Can't we perform such a simple operation as CLOSE a position like we did in MT4?

[---]

Look up PositionClose in the CTrade class.
I'm sure it will be the same as yours. One conclusion is inescapable - there is no other way.

But I support your request. I ask developers to consider this variant.

Add TRADE_ACTION_CLOSE operation type - closing of a position for a specified symbol in its volume at the current price.

[Yedelkin]

stringo:

Actually, there is a full 8 bytes of information for the message, which can be interpreted any way you want. It can be datetime, double, 4 short, 8 char, or 64 bits bit by bit.

With fours, 4 bytes of magic was enough to encode anything, but now we have 8. It would be only wishful thinking.

About 8 bytes in long and ulong was clear from the Reference. What's troubling is the inconsistent use of these types in relation to magic.

A simple example: it is acceptable to assign request.magic=ULONG_MAX-1 when sending a trade request. Why does the Reference Manual say that the OrderGetInteger(ORDER_MAGIC ) function returns only long type? Moreover, magic also returns long type for both positions and trades.

So, how was it originally designed? Maybe, we should specify forstruct MqlTradeRequest that magic is of long type, because functions HistoryDealGetInteger(), PositionGetInteger(), OrderGetInteger() etc. are not intended to return integer values greater than LONG_MAX?

[[Deleted]]

Yedelkin:

The 8 bytes of long and ulong was clear from the Reference Manual. The inconsistent use of these types in relation to magic is troubling.

A simple example: when sending a trade request, it is acceptable to assign request.magic=ULONG_MAX-1. Why does the Reference Manual say that the OrderGetInteger(ORDER_MAGIC ) function returns only long type? Moreover, magic also returns long type for both positions and trades.

So, how was it originally designed? Maybe, we should specify forstruct MqlTradeRequest that magic is of long type, because functions HistoryDealGetInteger(), PositionGetInteger(), OrderGetInteger() etc. are not intended to return integer values greater than LONG_MAX?

Actually the magik is of long type (this can be easily checked by forming a negative magik and a magik with a value outside the value range oflong type ).

To check it, we can slightly modify the Night Expert Advisor (it doesn't use classes of the standard library).

To make the experiment clean, we should change the EA_Magic parameter type to long and unwind the magician of the last order in the history (if the order has been successfully set).

[Yedelkin]

Interesting:
В действительности магик имеет тип long (это легко проверяется формированием отрицательного магика и магика со значением выходящим за диапазон значений типа long).

If so, a clarification must be made in the description of the magic element of theMqlTradeRequest structure, removing the letter "u" from the type name.

[[Deleted]]

Yedelkin:
If so, it is necessary to clarify description of magic element ofMqlTradeRequest structureby removing "u"from type name.

It is a good idea to make changes in CTrade class as well (if developers don't want to limit magic value to positive values only).

[---]

stringo:

Actually, there is a full 8 bytes of information for the message, which can be interpreted any way you want. It can be datetime, double, 4 short, 8 char, or 64 bits bit by bit.

With fours, 4 bytes of magic was enough to encode anything, but now we have 8. It would be only wishful thinking.

Actually, it's not 64 but only 63 bits (i.e. 8 bytes incomplete). It would be 8 bytes if we used the whole long range.

But unfortunately...

On the one hand, magic ulong is passed into MqlTradeRequest structure. It means that only positive values can be set.

On theother hand, the PositionGetInteger/OrderGetIntegerfunctions return the long type . It means that half of the ulong range is cut off.

What we have in fact is 63 bits instead of the 64 bits described above. Actually, it is not so much bad as great inconvenience to the principles of order checking.

It would be much more convenient to use the same system as in MT4 - allow magicians with a sign. Since many trading systems are based on a simple principle using the very symbol of a magician. Since it is much easier to divide one system into two and filter out your orders using the usual MathAbs( OrderMagicNumber() ) function.

[Renat Fatkhullin]

sergeev:

Actually it is not 64 but only 63 bits (i.e. an incomplete 8 bytes). 8 bytes would be if the entire long range was used.

You are mistaken.

64 bits are used and it's up to you how you use them. Long/ulong makes no difference, it all depends on how you interpret those 64 bits. If you want to use long as a signed long - use it, if you want to use it as an unsigned ulong - no problem. If you want to use other data types in these 64 bits, do it.

This is exactly what Slava wrote about.

[Vladimir Gomonov]

sergeev:

Actually it is not 64 but only 63 bits (i.e. an incomplete 8 bytes). 8 bytes would be if the whole long range was used.

But unfortunately...

On the one hand, magic ulong is passed into MqlTradeRequest structure. It means that only positive values can be set.

On theother hand, the PositionGetInteger/OrderGetIntegerfunctions return the long type . It means that half of the ulong range is cut off.

What we have in fact is 63 bits instead of the 64 bits described above. Actually, it is not so much bad as great inconvenience to the principles of order checking.

It would be much more convenient to use the same system as in MT4 - allow magicians with a sign. Since many trading systems are based on a simple principle using the very symbol of a magician. Since it is much easier to divide one system into two and filter out your orders using the usual MathAbs( OrderMagicNumber() ) function.

I'm honestly puzzled. You guys are overdoing it on no big deal. Absolutely not at all. This problem doesn't exist, you just made it up. Sort out the type conversions all the way to the end.

I hope the piece below helps you. Copy it into a script, compile it, run it in the terminal and then think very carefully. Good luck.

void OnStart()
  {
    Print("//------ ");

    int i_A = -100;
    uint ui_B = uint(-100);
    
    Print(i_A," ",uint(i_A));
    Print(int(ui_B)," ",ui_B);

    i_A = int(4294967196);
    ui_B = 4294967196;

    Print(i_A," ",uint(i_A));
    Print(int(ui_B)," ",ui_B);
//--
    long l_A = -100;
    ulong ul_B = ulong(-100);
    
    Print(l_A," ",ulong(l_A));
    Print(long(ul_B)," ",ul_B);
   
    l_A = long(18446744073709551516);
    ul_B = 18446744073709551516;
    
    Print(l_A," ",ulong(l_A));
    Print(long(ul_B)," ",ul_B);
  }