Dukascopy Support Board

PendingPositions class bug?
Page 1 of 1

Author:  isomorph [ Sun 20 Jan, 2019, 20:59 ]
Post subject:  PendingPositions class bug?

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;

    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;

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.html

IOrder.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.

Author:  vadim_berezhnoj [ Mon 21 Jan, 2019, 10:35 ]
Post subject:  Re: PendingPositions class bug?


To understand the difference, please check in the code how OpenPositions and PendingPositions lists are formed.

If you have questions or doubts in the code generated by Visual JForex please send it to [email protected].
These questions are out of the scope of that forum.

Kind regards, Support Team.

Author:  isomorph [ Tue 22 Jan, 2019, 19:12 ]
Post subject:  Re: PendingPositions class bug?

Apologies Vadim, I did not write correctly. You are right, OpenPositions are constructed with orders == IOrder.State.FILLED, and PendingPositions with order == IOrder.State.OPEN.

I got confused by the double condition check inside the LoopViewer. Not used to the Java grammar anymore.

  Page 1 of 1