
You are missing trading opportunities:
- Free trading apps
- Over 8,000 signals for copying
- Economic news for exploring financial markets
Registration
Log in
You agree to website policy and terms of use
If you do not have an account, please register
Changed
Now without alerts.
The answer is obvious - if Ticket == PrevTicket ---> return WRONG_VALUE.
If function returns value less than zero, then it should be called again.
The answer is obvious - if Ticket == PrevTicket ---> return WRONG_VALUE.
So, this is a solution of a special case of the problem which I described for clarity in the form of equality of neighboring tickets.
The problem is actually the same - indexing shakeout during the loop. This can lead to a situation where some ticket is skipped, or a ticket is repeated in one, etc.
I haven't found an alternative to IsChange.
So this is a solution to a particular case of the problem, which I described for clarity in the form of equality of neighbouring tickets.
The problem is actually all the same - shaking of indexing during the cycle. This can lead to a situation where some ticket is skipped, or a ticket is repeated in one, etc.
I haven't found an alternative to IsChange.
We create a list in the timer and work with it.
Create a list in the timer and work with it.
Better in code.
Better in code.
It is very difficult to show in code - there is a whole library of interrelated classes.
The idea is the following - we pass all orders and positions on the account and fill the CArrayObj list in the timer. We constantly update it to get actual information in one pass.
If there is a need to close positions or to delete orders, we obtain this list and select from it the necessary order objects and their tickets that are needed for the closing (modification) functions. If this order-object is physically absent (it was closed or deleted during these actions), we simply move on to the next object in the list, since this one has already been closed, and the list will be updated at the next iteration of the timer. The first problem that comes to mind is that the list is irrelevant when the trading environment changes during the time the actions are performed on the list. But as I see it, physical absence of an order from the list should not bother us too much - we just get an error and go to the next one in the list - this list is not shuffled like in a trading environment and skipping is impossible - only a statement of the fact of absence of an order corresponding to an entry in the list.
This is what I think so far, since I haven't implemented it in my code yet. I am just getting ready for implementation, but initially I need to finish some other classes (I asked a question about substitution of functions in Features branch). When I start the implementation, possible problems will be visible there, and I will decide how to solve them and fix them.
The answer is obvious - if Ticket == PrevTicket ---> return WRONG_VALUE.
If the function returns a value less than zero, we need to call it again.
You don't have to do anything at all. It is enough to follow the logic looking like an idiot.
We have 6 orders
We start going through the orders for, let's say, modification,
We choose 5 ticket 105, check if we want to modify it and modify it.
At this time, our unclean hands deleted order 2 ticket 102, and the list was changed. Now the order with ticket 105 is fourth in the list, and it is again selected for modification. But we do not work without checking... we checked if it should be modified, BUT!!! It doesn't... so what??? Who got hurt because the order was re-selected?
It is very difficult to show in code - there is a whole library of interrelated classes.
The idea is the following - we pass all orders and positions on the account and fill the CArrayObj list in the timer. We constantly update it to get actual information in one pass.
If there is a need to close positions or to delete orders, we obtain this list and select from it the necessary order objects and their tickets that are needed for the closing (modification) functions. If this order-object is physically absent (closed or deleted during these actions), we simply switch to the next object in the list, since this one has already been closed, and the list will be updated at the next iteration of the timer. The first problem that comes to mind is that the list is irrelevant when the trading environment changes over the time of the actions on the list. But as I see it, physical absence of an order from the list should not bother us too much - we just get an error and go to the next one in the list - this list is not shuffled like in a trading environment and skipping is impossible - only a statement of the fact of absence of an order corresponding to an entry in the list.
This is what I think so far, since I haven't implemented it in my code yet. I am just getting ready for implementation, but initially I need to finish some other classes (I asked a question about substitution of functions in Features branch). When I start the implementation, possible problems will be visible there and I will decide how to solve them and fix them.
Here is an implementation of this
Forum on trading, automated trading systems and trading strategies testing
Organizing an order loop
fxsaber, 2017.09.11 20:29
After sending a trade order, the trade environment changes, so it is advisable to execute all the trade logic of the TS from scratch immediately after the trade server response.
Only it still requires IsChange. The timer is not an option at all. Even Sleep(1) spoils the whole picture.
Absolutely nothing needs to be done. It's enough to walk through the logic with the look of an idiot.
Taki, yes, not a problem if closing/activation of an order is checked.
Well and if its own array of ticks, then the order will just miss.
ps. Let me throw in another case - if a pending order is set to stop a real order (for a rollover), then when the stop is triggered, the pending order may be delayed in opening for an indefinite amount of time. That is, one order will be triggered by the market, while the other will hang for a certain amount of ticks...
Here is an implementation of this
Only it still requires IsChange. The timer is not an option at all. Even Sleep(1) spoils the whole picture.
IsChange() is exactly implemented in the timer (the test version has not been finished yet):
The control class can catch the change either by the number returned from Refresh() of both classes (in the tester):
or in a user event, which are not yet implemented (demo, real).
IsChange() is exactly what is implemented in the timer (not yet completed test version):
Why, if IsChange is five lines?