The order gets physically sent to the broker only after tracker's submit method is called. The purpose of splitting order submission from the order preparation {@see IBroker} is to allow user to attach its event handlers and avoid raceconditions what events may start flowing before user is prepared to receive them.
What distinguishes tracker that corresponds to a closed order from the one that corresponds to an open order, is the orderCompletion property. For closed orders its not null and gives a convenient summary of the order final state. Note that for closed orders some brokers may not provide detailed execution information, but instead provide only final "gross" view.
orderCompletion being null tells that order has not been completed at the moment when method was called. By the time it returns, it may already be completed! There are two ways to deal with this "volatility" that fit different programming styles: event-oriented processing, and synchronous processing. To get notified of the order events, application may attach to the tracker's event source. It is better done before submit() was called, so that it is guaranteed that no events has been missed. Then, event-processing code may analyze the message type and content to monitor the order state changes. Note that history in the tracker is updated before event is sent by the tracker. This guarantees that application code sees already updated event history in the event handling code.
Application may choose to wait till the order completes, and then analyze the completion by looking at orderCompletion and/or history properties. There are waitForCompletion methods for doing this.
History:
- [06.12.2007] Created (Mike Kroutikov)
@author Mike Kroutikov
| |
| |
| |