In VJF, after setting input to 2 Loop Viewer blocks with OpenPositions and PendingPositions array of data, then exporting to Java code, I noticed the following:
private void LoopViewer_block_192(Integer flow) {
List<IOrder> argument_1 = OpenPositions;
for (IOrder order : argument_1){
if (order.getState() == IOrder.State.OPENED||order.getState() == IOrder.State.FILLED){
this._open_position = order;
}
LoopViewer_block_193(flow);
}
}
private void LoopViewer_block_193(Integer flow) {
List<IOrder> argument_1 = PendingPositions;
for (IOrder order : argument_1){
if (order.getState() == IOrder.State.OPENED||order.getState() == IOrder.State.FILLED){
this._pending_position = order;
}
CloseandCancelPosition_block_46(flow);
}
CloseandCancelPosition_block_194(flow);
}
the state of the orders that is tested is the same for both classes, OpenPositions and PendingPositions, namely: IOrder.State.OPENED and IOrder.State.FILLED. It is also these same states if using AllPositions class.
So in other words, there is no difference at all in terms of the state that any of these 3 classes keep track of.
Therefore how does one in VJF test for any pending, ie limit orders, that may need to be cancelled and removed from the book if certain conditions are true?
Or, if I read this API page correctly:
https://www.dukascopy.com/client/javado ... State.htmlIOrder.State.OPENED means limit orders?
In which case then there is no need to use OpenPositions or PendingPositions classes, but only AllPositions class in LoopViewer block?
Could you please confirm this is the correct understanding?
Also, in case something goes wrong with the logic of code or an exception is thrown, would it not be safer to assign the ouptut of the LoopViewer block to a user variable other than open_position because if the loop is interrupted and one uses open_position in other blocks as the only variable to keep track of the current open position, there would be a risk that the LoopViewer block leaves the state of variable open_position in the wrong state, which when used in another block could cause this block and the logic attached to it to give completely unexpected results and thus cause the strat to fail? open_position has strategy class scope.
