API Support wrote:
fxeconomist wrote:
However, closes are not reflected until they are done. My strategy could probably read an order as still on the table though I requested a close().
Therefore, there should be at least an intermediary IS_CLOSING state, that is set to the order right after close(), and until it becomes CLOSED.
How would you detect this state from another computer? That is:
- Assume that on one pc you send a close request and the position is in state IS_CLOSING.
- The other pc, however, won't be able to update the same position to IS_CLOSING state, until it receives some update from the server.
- Most likely that such update of IS_CLOSING state would arrive together with confirmation/rejection of the position close.
Then what is the sense of such state?
Yes, you are right, it needs an answer from the server. Quite similar happens when sending an order: there is no immediate switch to SUBMITTED, before OPENED. But OPENED is quite fast, I see many OPENED orders with a getOpenPrice() of 0.
I presumed that CLOSED requires effectively to close the order, implies the entire execution, and is much more slow than CANCELED, actually, it's as slow as FILLED.
During the execution, after I send the request, onTick may be fired, execution continues, therefore I should be able to tell the the algo "disregard these orders, as I said they should be closed". Since the CLOSED would come a bit later, the only way to do it is to provide an internal list with the labels of the orders requested to be closed, so that they are bypassed by the procedure looking for active orders. Later, they have to be removed from the list when ORDER_CLOSE_OK comes. So yes, it would rather help internally.
Any strategy that resides on a client's computer at home is prone to mistakes - power outage, internet connection failures, etc. In the end, strategies that really work will reside actually on your servers, so the connection to your trade server would work flawless.
