OrderSend() questions - page 6

[Mykola Demko]

maryan.dirtyn:

I'm racking my brains... the stop just won't set... and a lot of errors. this is what's left of the experiment, and it doesn't work any more

If I do this, there are no errors, but the stop-loss is still not set

answered here

[Mykola Demko]

Yedelkin:

Apparently, I didn't explain the previous problem very clearly. Let me try again.

During the last year, the description of theENUM_ORDER_TYPE_FILLING enumeration value list has been changed at least three times. The previous description looked as follows

ENUM_ORDER_TYPE_FILLING

Identifier	Description
ORDER_FILLING_FOK	A trade can only be executed in the volume specified and at a price equal to or better than that specified in the order. If there is not enough supply on the market at the moment for the order symbol then the order will not be filled. This filling type is used in the SYMBOL_TRADE_EXECUTION_INSTANT execution mode or SYMBOL_TRADE_EXECUTION_REQUEST.
ORDER_FILLING_IOC	An agreement to execute a trade at the maximum volume available in the market within the volume specified in the order and at a price equal to or better than that specified in the order. In this case no additional orders will be placed for the missing volume. This filling type can be available only in the execution modes SYMBOL_TRADE_EXECUTION_MARKET andSYMBOL_TRADE_EXECUTION_EXCHANGE depending on the settings on the trade server.
ORDER_FILLING_RETURN	Agreement to make a trade at the maximum volume available on the market within the volume specified in the order and at a price equal to or better than that specified in the order. In this case an additional order will be placed for the missing volume at the price specified in this order. This filling type is used only for pending orders (TRADE_ACTION_PENDING).

As we can easily see, there is a one-to-one correspondence between ORDER_FILLING_RETURN and pending orders, namely: ORDER_FILLING_RETURN could be applied only to pending orders and the type_filling fieldof all pending orders could be filled only with the value of ORDER_FILLING_RETURN.

For market orders(action==TRADE_ACTION_DEAL) the field type_filling should have been filled out depending on the execution modes set on the server side.

Thus we had a certain paradigm: if there was a pending order,ORDER_FILLING_RETURN; if there was a market order, ORDER_FILLING_FOK or ORDER_FILLING_IOC (depending on the mode).

Now everything is turned upside down a bit, namely:

ENUM_ORDER_TYPE_FILLING

Identifier	Description
ORDER_FILLING_FOK	This order filling policy means that the order can only be filled to the specified volume. If there is not enough volume of the financial instrument in the market at the moment, the order will not be executed. The required volume can be compiled from several offers currently available in the market.
ORDER_FILLING_IOC	Indicates agreement to execute a trade to the maximum volume available in the market within the volume specified in the order. If full execution is not possible, the order will be filled to the available volume, and the unfulfilled volume will be canceled.
ORDER_FILLING_RETURN	This mode is only used for ORDER_TYPE_BUY_LIMIT and ORDER_TYPE_SELL_LIMIT orders. In case of partial execution the limit order with the remaining volume is not deleted but remains in effect. For ORDER_TYPE_BUY_STOP_LIMIT and ORDER_TYPE_SELL_STOP_LIMIT orders the corresponding ORDER_TYPE_BUY_LIMIT/ORDER_TYPE_SELL_LIMIT limit order with the execution type ORDER_FILLING_RETURN will be created on activation.

The restriction of using ORDER_FILLING_FOK and ORDER_FILLING_IOC only with market orders is gone. Also there is no restriction on using ORDER_FILLING_FOK and ORDER_FILLING_IOC with market orders depending on the execution mode set on the server. There is a restriction on using ORDER_FILLING_RETURN only with limit and stop_limit orders .

So my question is: Is it acceptable to use ORDER_FILLING_FOK and ORDER_FILLING_IOC at all for all orders (both market and pending) including limit and stop_limit orders? Has anyone figured out the changes?

Yep, it's a bit murky on this issue.

If there is full correspondence between ENUM_SYMBOL_TRADE_EXECUTION and ENUM_ORDER_TYPE_FILLING then the second one is obviously unnecessary.

Hence there is no morality, and most likely different values ofENUM_ORDER_TYPE_FILLINGare acceptable with one and the sameENUM_SYMBOL_TRADE_EXECUTION value . MQ would describe a table of possibilities here, but most likely this data is dependent on the dealing server settings.

And hence the second moral, what is needed after all:

a function is needed which would return a list of valid options (ENUM_ORDER_TYPE_FILLING), for the requested order type (immediate or pending).

There aren't many options there, so you can shove in int via "|".

If I'm wrong, give me a magic wizard, where to look for this question.

[Mykola Demko]

To solve this question, I went to the standard library (as a matter of habit, if it's not clear to see how others do it).

The function for convenient inheritance was given there, while in the CTrade class SetTypeFilling() is not used, the field type_filling is initialized by default zero which corresponds to ORDER_FILLING_FOK according to the enumeration.

That's all, no more work. And I thought that since this field isn't present in interface, it means that filling is automated in class.

SZY in general, waiting for an answer, how to fix it :)

[Serj]

For now, I see one way out: pounding the server until it gives you the answer you need.

[Mykola Demko]

her.human:
So far, I see one solution: pound the server until you get the answer you want.

A good night's entertainment, made me laugh to my stomach.

The Chinese hacked into the Pentagon's main server.

Every Chinaman has tried once to type the password.

Every other person typed in "Mao Tse Tung".

On 5*10^7 tries, the server says the password is "Mao Tse Tung."

[---]

her.human:
For now, I see one way out: pounding the server until you get the right answer.

stupid way out.

You should talk to your DC first. Find out what types of execution they support and what types of metaquot list correspond to their execution types.

because just because metaquotes came up with - 3 types of fill and 3 types of time - it doesn't mean that they are a reflection of reality when filling orders on a real broker.

[Mykola Demko]

sergeev:

stupid way out.

You should talk to your DC first. find out which execution types they support and which metaquote list types correspond to their execution types.

because just because metaquotes came up with - 3 types of fill and 3 types of times - it doesn't mean that they are a reflection of reality when filling orders on a real broker.

That's what I'm saying, it all depends on the server settings,

But knocking on every brokerage company is also a problem,

for example in one brokerage company you may get an order for a real brokerage,

but bypassing everything and writing switch dillings in your code is overkill.

If you feel that you have already registered with us, you may start from the beginning,

PS you agree that normal code is written in a unified way, for any dealing, exceptions are possible but at first exceptions confirm the rules, and secondly if there are exceptions you have to write the exceptions.

Here such a tautology turns out.

[---]

Urain:

That's my point, it all depends on the server settings,

But it would be problematic to knock to each brokerage company,

If you do not know the difference between the two, you may think that the order will be copied to the right one,

but bypassing everything and writing switch dillings in your code is overkill.

PS you should agree that the normal code is written in a unified way, for any kind of dealing,

PS you agree that normal code is written in a unified way, for any dealing, exceptions are possible but first exceptions only confirm the rules, and secondly if there are exceptions you have to write the exceptions. Here such a tautology turns out.

here's the thing.

the metaquotes are messed up with execution types and execution times. they are non-standard in the sense that in reality IOC and FOK orders refer to execution times.

The order's execution type used to be adequately named AON. but it was then removed.

Look at the FIX specification which FC uses and executes orders

FIX 4.4 : TimeInForce <59> field

Type: char

Used In
Description

Specifies how long the order remains in effect. Absence of this field is interpreted as DAY. NOTE not applicable to CIV Orders.

Valid values:
0 = Day (or session)
1 = Good Till Cancel (GTC)
2 = At the Opening (OPG)
3 = Immediate or Cancel (IOC)
4 = Fill or Kill (FOK)
5 = Good Till Crossing (GTX)
6 = Good Till Date
7 = At the Close

I have marked types that took meta quotas to themselves. But as you can see they all are in one group of the TimeInForce tag <59>.

And now please tell me how the broker who places bids at the market will process the put type IOC and time GTD in the MT order. Because this is one field, not two different ones.

Therefore, each broker will think for himself what to do with the filling and what type to use and how to withdraw the order.

The only saving grace is the difference between the market and pending order, i.e. some types of order execution are used only for pending orders and others for market ones. Generally, we should look at this point and discuss it.

The name All-Or-Nothing is located in another tag, ExecInst <18>, which is not passed to MetaTrader in any way. It is implicitly assumed (probably) for FOK type

[Mykola Demko]

sergeev:
...

Alex take over this topic please. I'm unfortunately a floater on these issues.

Make suggestions to the SD, talk to them.

We need to put the topic in some kind of order.

What we have now is not at all usable for professional programming.

[---]

Urain:

Alex, take over this topic please. I'm unfortunately a bit of a swimmer on these matters.
Make suggestions to the sd, talk to them.
We need to put the topic in order.
I am not sure what we have now is suitable for professional programming.

Ha. Either I'm stupid or my skis aren't moving.

You yourself see that every month methaquotes makes a connection to a new exchange or market.
From which I conclude that in this state of affairs their programmers dock MT and FIX without problems (or with some strain with limitation of one of them).
So they can combine FOK and GTC time types, which means they are unlikely to change anything in the foreseeable future, as the work is in progress.
At the same time (I understand), that for exchange the bridge from MT can set only two types - AON or Partial. And invented in MT Return - probably goes to Partial.

In general, the issues of interaction FIX broker and MT server lie in the plane of skill and understanding progeries at the broker, who make bridges from MT to their providers. And I do not think that metaquotes will change anything, because they have long and actively promote the platform to the markets, and therefore the internal structure of MT server quite consistent with the realities.