How to check if an order is selected - page 4
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
In fact, there's a lot of demagoguery going on.
All we need to know if an order is selected or not.
I explained it in the beginning of the topic, isn't it clear?
We have some function that potentially handles orders, i.e., it selects them and analyzes. It can be called from different code fragments, including those that already have an order selected to work with. If this separate function does not save the order already selected and restore its selection, this will lead to errors in the EA logic, since when we return from this function, the order selected before it was called will be wrong. So, to avoid these errors, we need to remember the currently selected order from the place of its call in each auxiliary function that handles orders by itself and return its selection when it is done. How to accomplish this task easily and without generating errors - this is the question of the current theme
// It implies that an order is selected through OrderSelect (or there is an error).
Why an error? If the order is not selected, this action is simply not necessary, but it seems to be impossible to find out in advance if the order is selected or not without special tricks
// So why should it be selected again?
That is why after returning from this function into the calling part of the code, the order selected in this part of the code before the call of the function remains selected - so that operations that are performed with the currently selected order do not lead to errors
No, he's really in the tank.
I explained everything at the beginning of the thread, is it so unclear?
We have some function that potentially works with orders, i.e. it selects them and analyses them. It can be called from different code fragments, including those that already have an order selected to work with. If this separate function does not save the order already selected and restore its selection, this will lead to errors in the EA logic, since when we return from this function, the order selected before it was called will be wrong. So, to avoid these errors, we need to remember the currently selected order from the place of its call in each auxiliary function that handles orders by itself and return its selection when it is done. How to accomplish this task easily and without generating errors is the question of this very topic
1. To pass to the function the number of the order selected before it was called.
2. When the function finishes, re-select the same order.
How do I know what you want to get? You'll have to be more specific :(
1. Send the number of the order selected before the function is called.
2. When the function finishes, re-select the same order.
How do I know what you want to get? You should be more clear :(
Yes, I understand it, however, I would like to write informational functions, such as total profit or open orders, which can be called without thinking that they will change something in the program execution logic. This makes sense, I think.
It's not always trivial to pass the selected order in the calling function, imagine that the nesting of calls >1, should we pass a ticket to each function so that some minor info function could use it?
It would be more logical to give a wrapper to OrderSelect and OrderTicket, that would store and get information about the currently selected order from a separate variable, but here we end up with doubling of information (the terminal already knows if the order is chosen, but we can't pass this information without a potential error). So we either get duplication of information or excessive complication of functions (we also pass the selected order from the very top into each parameter), or forced generation of program execution errors.
Yes, I understand that, but I would like to write informational functions, such as total profit or number of open orders, which can be called without thinking that they will change the program's execution logic. This makes sense, I think.
It makes sense, but in this case we should at least divide the functions into "white" and "black" ones. The order number selected in the former is saved, and when it is violated in the latter, it is restored.
It seems simple enough.
Yes, I understand that, but I would like to write informational functions, such as total profit or number of open orders, which can be called without thinking that they will change the program's execution logic. This makes sense, I think.
It's not always trivial to pass the selected order in the calling function; imagine that the nesting of calls >1, shouldn't we pass a ticket to each function so that some minor info function could use it?
Look at Kim's function library and you will see that each function is enumerating, selecting and checking the ticket, and then what you need to know. Your "logic" does not allow you to learn the basic rules of programming.
You have an elder in a field, and an uncle in Kiev.
Look at Kim's function library and see that each function does the enumeration, selection and check of the ticket, and then what needs to be learned. Your "logic" does not allow you to learn the alphabetical rules of programming.
A little elder in a garden and a little uncle in Kiev.
Boris, it's not necessary. I'm talking about the ABCs.