Trouble Selecting Order properly when part of it closed - page 2

 
ubzen:

Here's a possible solution I just coded. This helped explain some question I had about partial close. My solution is because generally you know where your orderSend and orderClose commands are, adding the ticket numbers to an array is the best I can think of. Other simple solutions like if Ticket# is greater than Known Ticket# then its a partial close came to me but that breaks if you open more than one order at a time.

To make the codes more reliable to shutdowns, look into saving the value of the Arrays to file because I dunno if Arrays save their value between shut-downs. To test code save as EA, as Script might work as well. This solution is new to me and I could have missed something so use with care.

EA's must be programed to recover, terminal restart, OS crash, power glitch, etc.

Either you must implement permanent storage on disk (Global Varables will not be stored on a OS crash/power) or you must have a orderSelect loop.

I just use the orderSelect loop. For a partial close it is only necessary to prevent a second close. So move the SL to break even, and then partial close. On a restart, orderSelect loop will find SL at BE or better - no partial close. No disk, no arrays.

You HAVE to use the orderSelect loop anyway, if orderSend returns timeout the trade may or may not have been opened. You have to wait for a reconnect and find out.

 
Funky:

Hi guys.

A quick question, but I have tried many things.

I have been closing parts of orders, and then basing decisions of the rest on the part of the order that is still in MODE_TRADES, and unfortunately it uses the info from the orders from MODE_HISTORY at the same time (even if I give that ticket a variable, which is not supposed to be accessed from history according to dictionary last I remember).

Is there a way around this? I mainly want to check if an order is still alive, either by ticket or magic (yet to try by comment, but rather not go that way), but it is looking in history as well, after the orders are split up, even once the trade closes in MODE_TRADES.

Is there a walk around for this?

The documentation is telling us to somewhat create our own "filter" after we have done OrderSelect - using either OrderCloseTime()!=0 or OrderCloseTime()==0 to select our choice, of which pool(TRADES or HISTORY). Here's what it says:

The pool parameter is ignored if the order is selected by the ticket number. The ticket number is a unique order identifier. To find out from what list the order has been selected, its close time must be analyzed. If the order close time equals to 0, the order is open or pending and taken from the terminal open positions list. One can distinguish an open position from a pending order by the order type. If the order close time does not equal to 0, the order is a closed order or a deleted pending order and was selected from the terminal history. They also differ from each other by their order types.

I got this from looking at OrderSelect() definitions here: O/Ref: https://docs.mql4.com/trading/OrderSelect

 

@WHRoeder: On a restart, orderSelect loop will find SL at BE or better.

How will this differentiate between Normal Orders with SL at Break-Even or Better?

Wouldn't this limit the partial close to Only orders which are in Profit?

What if you don't want the SL at BE, wouldn't this Limit your strategy?

For a partial close it is only necessary to prevent a second close.

I don't get what you mean by this, are you saying with your method.

I cannot implement a partial close a second time and maintain the difference?

 
ubzen:

There must be something wrong with your codes. I don't get why it would be looking in history unless you're asking for mode_history somewhere. This is the area you should focus most of your attn.

if(OrderSelect(MYSELLTICKET,SELECT_BY_TICKET)==true)....make sure to add mode_trades here.

Thanks, yeah I was finding it was searching for that ticket in both MODE_TRADES and MODE_HISTORY when by definition, it is only supposed to look MODE_TRADES if you SELECT BY TICKET...


ubzen:

Here's a possible solution I just coded. This helped explain some question I had about partial close. My solution is because generally you know where your orderSend and orderClose commands are, adding the ticket numbers to an array is the best I can think of. Other simple solutions like if Ticket# is greater than Known Ticket# then its a partial close came to me but that breaks if you open more than one order at a time.

To make the codes more reliable to shutdowns, look into saving the value of the Arrays to file because I dunno if Arrays save their value between shut-downs. To test code save as EA, as Script might work as well. This solution is new to me and I could have missed something so use with care.

Much appreciate Ubzen, I will have a play around. For the time being, I got sick of beating my head, and thought of a walkaround, and settled not to do a partial close on one particular order, then based my EA around that... It was a big compromise, so I will keep you posted over time if I get it going. Thank you for your time. Those array ideas look interesting, I will study it in more detail, thanks.



WHRoeder:

EA's must be programed to recover, terminal restart, OS crash, power glitch, etc.

Either you must implement permanent storage on disk (Global Varables will not be stored on a OS crash/power) or you must have a orderSelect loop.

I just use the orderSelect loop. For a partial close it is only necessary to prevent a second close. So move the SL to break even, and then partial close. On a restart, orderSelect loop will find SL at BE or better - no partial close. No disk, no arrays.

You HAVE to use the orderSelect loop anyway, if orderSend returns timeout the trade may or may not have been opened. You have to wait for a reconnect and find out.


Thanks WHRoeder, I see you were refering to that code. I would settle for a power down glitch if it would work, however good point mentioned.



diostar:

The documentation is telling us to somewhat create our own "filter" after we have done OrderSelect - using either OrderCloseTime()!=0 or OrderCloseTime()==0 to select our choice, of which pool(TRADES or HISTORY). Here's what it says:

The pool parameter is ignored if the order is selected by the ticket number. The ticket number is a unique order identifier. To find out from what list the order has been selected, its close time must be analyzed. If the order close time equals to 0, the order is open or pending and taken from the terminal open positions list. One can distinguish an open position from a pending order by the order type. If the order close time does not equal to 0, the order is a closed order or a deleted pending order and was selected from the terminal history. They also differ from each other by their order types.

I got this from looking at OrderSelect() definitions here: O/Ref: https://docs.mql4.com/trading/OrderSelect

Hi Diostar. Thanks for your time here too. I ended up having to use that way of selecting an order out of History earlier in my EA. I found it really really ironic that after a parital close, I can't avoid selecting that ticket in History if part of the same order is still alive (even if SELECT_BY_TICKET, MODE_TRADES etc). Good point though, it has got a lot of us that one, me included for ages.


ubzen:

@WHRoeder: On a restart, orderSelect loop will find SL at BE or better.

How will this differentiate between Normal Orders with SL at Break-Even or Better?

Wouldn't this limit the partial close to Only orders which are in Profit?

What if you don't want the SL at BE, wouldn't this Limit your strategy?

For a partial close it is only necessary to prevent a second close.

I don't get what you mean by this, are you saying with your method.

I cannot implement a partial close a second time and maintain the difference?

Yeah I was a little confused here too, however I didn't consider it in detail as I am closing part of the order quite a few times. I am still not on par with you guys, but find these discussions great for my learning, so thank you.

In the end, I was unable to get FX1net's solution to work for me. However I settled for a logistical solution of not closing part of one order and then I hinged other decisions off that one. Previously the the EA thought that order was closed because cause it gets selected in HISTORY as well as TRADEs at the same time when you select either by TICKET, or MAGIC number... after part of the order is closed and part of it is alive.... So I can;t aviod the EA thinking that the trade is closed when I select by these methods... Whereas previously I had to do as Diostar said, and use OrderCloseTime, to actually check if the order was closed, as I couldn't select by TICKET or anything out of HISTORY.... The one was a real headspin for me, I really appreciate those ideas.

Reason: