Questions from a "dummy" - page 12
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 ADVISE ON THE MOBILE PHONE TERMINAL.
WHEN AND WHEN WILL ANY SUPPORT FOR USER INDICATORS (NON STANDARD) OR CONSULTING ON mql4 OR mql5 be REALIZED?????????????????????????????
ON WHICH PLATFORMS (ANDROID FOR EXAMPLE) THIS WILL BE IMPLEMENTED????????????????? AND HOW SOON?????????????
awaiting ANSWER, thanks for the heads up
Interesting:
Well I disagree with that conclusion. OCO == "one cancels the other". Well, there's no such thing in MT5 where one order cancels the other one. I've been regretting it for a year.Features such as SL and TP really close an open position, but the issue of "canceling" pending orders has nothing to do with it.
They do, but these orders are implemented on the server. And they are the only ones actually integrated into the OCO scheme so far (and we would not dream of implementing "If Done" orders directly in the terminal and on the server).
When opening a position and setting TP and SL in MT5 we essentially use the same form (but the result here is position + 2 canceled orders).
After your message, I have already commented on this situation taking into details the SL and TP canceled interchangeably. However, here I would like to add the following.
If authors of OCO orders had been told that in the 21st century their invention will be applied only to SL and TP levels, they would have been very surprised to see so much limitation of the application area of their brainchild :) .In fact, everything is upside down: All materials you read refer to the same thing: CCA orders are interchangeable orders whose types are now specified in MQL5 ENUM_ORDER_TYPE enumeration. I have never encountered any mention of the connection between CCA orders and SL-TP levels. So, the execution mechanism may be the same but it is ENUM_ORDER_TYPE orders the client executes but not SL-TP levels (according to MQ).
So when I am writing about pending orders I mean orders from ENUM_ORDER_TYPE list and not "derivative" orders based on SL-TP levels.
______________
* The "derivative" because each of the OCO orders can have different SL-TP levels.
Gentlemen, the root of understanding lies in the simplicity of the platform. Simplicity for 99% of users and a conscious rejection of complications that the remaining percentage of users can understand.
Ask yourself the question "what would it take to attract X million users to the financial markets? With enough experience, the answer will be close to "make a simple system, removing complexity and uniting traders in a single ecosystem".
Instead of piling up OCO order settings (the panel is really not for the average mind) we have offered a very simple and straightforward order management scheme with integrated SL/TP. The vast majority of OCO orders are just SL/TP for current positions. By putting SL/TP inside we have minimized the number of additional orders and greatly simplified deal management.
ps: the order system issue is closed
ps: the order system issue is closed
ps: the order system issue is closed.
It is a shame that it will not be possible to make normal (reliable) SLs/TPs for individual trades (not total positions).
This immediately cuts off the ability to (reliably) trade multiple strategies on the same instrument/account.
Hali-vor should not be resumed, I remember the opinion of developers (one instrument = one position = one SL and one TP)...
Which type (long or ulong) does ORDER_MAGIC actually belong to ?
ENUM_ORDER_PROPERTY_INTEGER
ORDER_MAGIC
Identifier of the Expert Advisor who placed the order (intended for each expert to place its own unique number)
long
Which type (long or ulong) does ORDER_MAGIC actually belong to ?
ENUM_ORDER_PROPERTY_INTEGER
ORDER_MAGIC
Identifier of the Expert Advisor who placed the order (intended for each expert to place its own unique number)
long
I think, the result should be converted to the type declared in the code (there can be a misprint in the documentation).
If we are speaking about MqlTradeRequest, in this case it is most probably (ulong).
In my opinion, the result should be converted to the type declared in the code (there may be a misprint in the documentation).
As for MqlTradeRequest, in this case it's most likely (ulong), but probably long will do without problems.
In general, the answer is not on the merits. The question was very clear: "what type (long or ulong) does ORDER_MAGIC actually belong to?"
Let's try to be substantive:
1. Both of these types can be declared without transformations.
2. If you use only positive values of magik, it's more profitable to specify its value as ulong (because there a range of possible values from 0 to 18 446 744 073 709 551 615).
3. On the other hand, the CExpert class of Standard Library applies long value in initialization (which allows you to specify negative values, but shifts the range of possible values). So, when initializing this class, the value of magik can already be from -9 223 372 036 854 775 808 to 9 223 372 036 854 775 808.
This statement should be checked.
4. But CTrade class (of the same standard library) already has a ulong value as it should be based on the query structure.
Let's make some preliminary conclusions:
a) Work with magik in CExpert and CTrade classes is not consistent, since in the first case long is specified, while in the other one ulong;
b) The classes in question were developed by different people, or the set and structure of parameters for certain functions in CExpert was written with CTrade in mind (which may or may not have existed in the past).
c) The work of experts associated with the development and documentation of the standard library is not fully coherent (although mostly seen a fairly good study of key issues).
d) If I understand correctly, the interaction of these two classes limits the value of the magician to a range from 0 to 9 223 372 036 854 775 808. This statement should be checked.
5. The MqlTradeRequest structure has the ulong type to work with magik. Everything is fully consistent with CTrade class, that's why it is more logical to specify the range of possible values of magician from 0 to 18 446 744 073 709 551 615 if we use only this class. This statement should bechecked.
PS
I think the developers intentionally "clamped" possible values of a Magician in the range from 0 to 9 223 372 036 854 775 808.
The developers seem to have deliberately "crammed" the possible values of a magik into a range from 0 to 9 223 372 036 854 775 808.
Actually, there's as much as 8 bytes of information given to magic, 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. All it takes is the will.