Dukascopy
 
 
Wiki JStore Search Login

PendingPositions class bug?
 Post subject: PendingPositions class bug? Post rating: 0   New post Posted: Sun 20 Jan, 2019, 20:59 
User avatar

User rating: 0
Joined: Tue 26 Jan, 2016, 04:18
Posts: 16
Location: CanadaCanada
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.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.


 
 Post subject: Re: PendingPositions class bug? Post rating: 1   New post Posted: Mon 21 Jan, 2019, 10:35 
Visual JForex expert at Dukascopy
User avatar

User rating:
Joined: Mon 22 Apr, 2013, 11:30
Posts: 533
Location: Ukraine, Kiev
Hello.

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.


 
 Post subject: Re: PendingPositions class bug? Post rating: 0   New post Posted: Tue 22 Jan, 2019, 19:12 
User avatar

User rating: 0
Joined: Tue 26 Jan, 2016, 04:18
Posts: 16
Location: CanadaCanada
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.


 

Jump to:  

  © 1998-2011 Dukascopy® Bank SA
On-line Currency forex trading with Swiss Forex Broker - ECN Forex Brokerage,
Managed Forex Accounts, introducing forex brokers, Currency Forex Data Feed and News
Currency Forex Trading Platform provided on-line by Dukascopy.com