Problem with LIMIT orders (maybe not arriving to server?) - page 2

New comment
 
mindundi24: I don't really understand, you mean order is filled right after it is selected? if so, shouldn't be any registry about the "buy" in account history? (there is not, order is a ghost)

Since we do not have access to your code, your logs or your order history - we can neither confirm nor deny the nature of what is indeed happening - we can only speculate!


mindundi24: Also, how do I re-orderselect then? I thought "break" after error make it jumps out of the loop, so my understand was if it goes back to the loop is because conditions are met again (is still Limit Order) (?)

By using OrderSelect() again as I stated, when it fails with an error. Obviously you will have to adjust and adapt your code accordingly!

Alternatively just re-loop as you stated, but your code as you have currently presented it, is inefficiency and you loop through the order history twice (counting and deleting). You can easily accomplish both and cater for other conditions with just a single loop.


mindundi24: I've been working with market orders until now, I'm porting now to limit system because obvious inefficiencies experienced in real account (demo account have perfect execution), I would save a lot of energy and time (and yours too, sorry about that) if I stuck to market orders, but it need to be limit.

Those "inefficiencies" will not disappear with the use of pending orders. They will suffer slippage and spread volatility just as much as Market orders.

Welcome to the "real" world! Those are the differences between back-testing, demo accounts and real accounts.

On real accounts, your code has to be written so as to compensate for slippage and volatile spread changes; and such code requires "real" trading experience and knowledge. That is just how it is on real accounts. Pending orders will not resolve that issue.

 

First of all Thanks for the answers, and for your time!


FMIC:

Since we do not have access to your code, your logs or your order history - we can neither confirm nor deny the nature of what is indeed happening - we can only speculate!

so what code is also needed?  for history, as said in OP it doesn't appears, is like it never happened! thats why I think order never arrived to server, terminal only find out about the "non-existent order" after restart terminal (error3=invalid trade parameters because there is no such order!).
also it doesn't happen always (I mean most of the time it send, execute or delete as expected), but it happens sometimes and when it does it floods forever.


FMIC:

By using OrderSelect() again as I stated, when it fails with an error. Obviously you will have to adjust and adapt your code accordingly!

Alternatively just re-loop as you stated, but your code as you have currently presented it, is inefficiency and you loop through the order history twice (counting and deleting). You can easily accomplish both and cater for other conditions with just a single loop.

can you show any example please? honestly I'm out of ideas.

 
mindundi24: can you show any example please? honestly I'm out of ideas.

Is it not obvious? If your condition for deletion, is if there be at least one pending order, then the first one you find will already satisfy that condition - so you can start deleting immediately! Hence, no need for two loops - just one!

If the deletion fails, just re-select and check if it has been triggered and converted into a Market order!

 

What you are saying is that the only filter OrderDelete loop have is it to be limit? that makes no sense, then no one single order would be filled ever... it obviously have other filters that need to be met.

About the other loop to count limit orders it is required for other matters, and since it is there I just use it as filter so the code process OrderDelete loop <only if> there is any limit order instead of every tick. But I already explained all of this: https://www.mql5.com/en/forum/160431

Anyway, remove "count order" filter won't solve the problem.

 
mindundi24:

What you are saying is that the only filter OrderDelete loop have is it to be limit? that makes no sense, then no one single order would be filled ever... it obviously have other filters that need to be met.

About the other loop to count limit orders it is required for other matters, and since it is there I just use it as filter so the code process OrderDelete loop <only if> there is any limit order instead of every tick. But I already explained all of this: https://www.mql5.com/en/forum/160431

Anyway, remove "count order" filter won't solve the problem.

It is not my fault it is not your "true" code. It is what you posted and we can only answer based on what you have stated.
if (countlimit > 0) //--> once limit orders are counted, in order to process delete code, it need to be at least one pending order active

Anyway, if your filter condition is not that one, you can still do it in one loop by using a classic state machine (computer science 101).

As for the rest, you will just have to figure it out yourself as you don't seem to want to research or follow up on the comments that have been provide thus far.

Since your information and code is also not very forthcoming, you cannot expect us to read your mind. You will just have to resolve it by your own devices then.

 

That's just the first filter!

if that filter is ok, then there are more filters in the second loop:

mindundi24:



      for ( i = OrdersTotal()-1; i >= 0; i-- )
        {
         if ( !OrderSelect( i, SELECT_BY_POS )) continue;
         if ( OrderSymbol() == Symbol() && OrderMagicNumber() == Magic && blah blah ) && ( OrderType() == OP_BUYLIMIT || OrderType() == OP_SELLLIMIT ))
           {
            if ( !OrderDelete(OrderTicket())) Print("Delete pending ERROR ", GetLastError()); break;
           }
        }


but again, this is not even relevant to the problem, the theory "order is deleted before it is even filled"  is not the case. Also it already jumps out of the loop if any error, so again, that's not the problem, it gets in the loop again and again because conditions are met, but the order can't be deleted or modified because there is no such order in the server, that could explain why when terminal is restarted the order that was giving error doesn't shows in any registry or account history, it never arrived to server, but terminal thought it did. All of it is explained in the OP already anyway.

My apologies if I express myself badly I thought I made everything clear but now I see I did not, again my apologies for that, and thanks again for the efforts and your time.

 

Hi!


Talking about deleting or closeing of orders not existing is useless.

1.) I assume you are not talking about backtesting.

2.) OrderSend will print in your Terminal and/or Expert Log - check it.

  - If you get a ticket after your OrderSend, call your broker.

  - If you get an error, fix your code.

 
eddie:

Hi!


Talking about deleting or closeing of orders not existing is useless.

1.) I assume you are not talking about backtesting.

2.) OrderSend will print in your Terminal and/or Expert Log - check it.

  - If you get a ticket after your OrderSend, call your broker.

  - If you get an error, fix your code.


Thanks for the answer!

1) Right, no backtesting but realtime (demo account).

2) Yes, what I mean is, if limit order is filled or else deleted it appears in Terminal>Account History as "buy" if it was filled or "cancelled" if deleted successfully but it doesn't. Although it appears on Terminal>Trade as "buy limit".

this is the log:

0 12:00:06.782 '1113753': delete pending order #152051418 buy limit 0.01 EURUSD at 1.08860 sl: 0.00000 tp: 0.00000
1 12:00:07.038 '1113753': deleting of pending order #152051418 buy limit 0.01 EURUSD at 1.08860 sl: 0.00000 tp: 0.00000 failed [Invalid parameters]

[...]and so on[...]


The thing is, I can't remove manually, and when I restart terminal there is no order, it dissapear from Terminal>Trade and of course is not on Terminal>Account History since it wasn't filled or cancelled.

 

Sounds similar to this bug. Except yours isn't there. Do you have an expiration on it ?

 
mac8008:

Sounds similar to this bug. Except yours isn't there. Do you have an expiration on it ?

 

Sorry, similar to what bug?

I don't use expiration, I did some test with it but looks like my borker use floating values for minimum expiration date, I mean random values, so I don't use it.

12
New comment