How to check if an order is selected - page 19
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 principle, yes, but the "pointer" will have to have its own pointer. think about my suggestion with the function, it seems to me a universal solution. of course there is a question about the speed of such code, but it seems to be the third question.
Thank you, always happy to have a constructive conversation.
So, if function A in the program selects some order in the loop and then calls auxiliary function B from the library, even if B selects another order in the process, the order selection in function A should not be affected by the return.
Thank you, always happy to have a constructive conversation.
You're welcome, just don't jump to conclusions.
If you store the value of the function in a variable, yes. If not, the function is global and may change on the first call.
I'm a bit confused. I meant the following situation: we call library function B() from function A() in the module of the main program, which, for example, simply selects the first order in the list (assuming that there is an order a priori):
void B(){
OrderSelect(0,SELECT_BY_POS);
}
When control returns from the library to the main module after this function has been called, if we call OrderTicket() or any other function in it that expects the order to be pre-selected, we will get exactly the same 4105 error. But if before the call of function B in the main module some other order has already been selected, it will remain selected regardless of the new Select in the library, because the currently selected order, as I understand it, is unique only within the module.
But if we call the same function B from function A of the main module, then the order selected in function A before the call to B will change to order 0 (that is, the currently selected order after returning from function B will be order 0, no matter what was the currently selected order before the call to B).
Therefore, if we call a function that uses OrderSelect by itself, we should make sure that when we return from this function the order we have chosen before we call this function, so that we can use it later. If you don't make sure of that, it can lead to hard-to-find logical errors in your code.
Specifically, the "pointer" - the state of the current order selection - is global within the module, i.e. this pointer is the same for the library and different for the program module. This means that if function A in the program selects some order in the loop and then calls the auxiliary function B from the library, then even if during its operation B selects another order, the order selection in function A should not be changed upon the return. But if both functions are within a module, then when returning from B function, we need to remember and restore the current order selection either before and after B is called in A function itself or in B function when it starts and finishes its work so that the logic of A function work is not violated at that point.
Your point is clear...
And I see an analogy with popular Expert Advisor's constructs when ticket numbers are stored in variables and used later (on next ticks, like if a byyticket was opened, etc.)...
If you want to get a ticket of the last opened order, just use properties of this order, OrderSelect() and everything will be fine.It means that at any moment, the Expert Advisor has to "understand" in what state the trade strategy is and act according to this state, no matter what happens with electricity and other working Expert Advisors in the terminal.
When control returns from the library to the main module after this function has been called, if we call the OrderTicket() function or any other function in it that was designed for the order to be pre-selected, we will get exactly the same 4105 error. But if before calling function B in the main module some other order has already been selected, it will remain selected regardless of the new Select in the library, because the currently selected order, as I understand it, is unique only within the module.
it has been proven to work this way, or do you think it works this way ?
To me there is no separation into modules and libraries... once compiled the code works as a single construct...
wherever OrderSelect() is called the same OrderTicket() of the last selected order will be returned...
I think it should work like this...
it's proven to work that way, or do you think it does ?
To me there is no division into modules and libraries... after compilation the code works as a single construct...
Wherever OrderSelect() is called the same OrderTicket() of the last selected order will be returned...
I think it should work like this...
It was checked that the order selected in the library is not the selected order when it is returned in the main module. Therefore, the order that is logically selected should be the last selected order in the main module, although I haven't checked it yet.
I solved this problem for myself by creating wrappers for library functions in the include library file mqh similar to the following one:
bool GetOrder(int a=0){
return(OrderSelect(_GetOrder(a),SELECT_BY_TICKET));
}
By the way, you cannot pass default parameters to library functions either.
Here _GetOrder(int a) is the library function itself that finds and returns some order. The function is called from the library with an explicit parameter "a", in the wrapper function it is 0 by default, plus the returned ticket in the wrapper is selected anew in the main program module, because its selection in the library function will not reach the "recipient".
I think so too, no matter where this function is called from, it will give a set of selected parameters for a particular order and the program will not change them until the next call to this function, no matter where that call comes from.
Why else would you wrap this function in an additional, completely unnecessary function?
PYSYS. Advice - create a static integer variable, pass the value of order after opening, it will not change, until you want it to, and will accurately perform what you have planned.
Checked that the order selected in the library is not the selected order when returning to the main module. So logically the selected order on return should be the last selected order in the main module, although I haven't checked this yet.
And this statement needs clarification: The statement is true if we are talking about a module (library) compiled ONLY (*.mg4-libraries from the libraries folder). For modules which are part of the main compiled file (*.mgh-library), this statement is NOT true!
MQH is not a separate module, but an insert in the main module, located in a different file. So of course we are talking about a separate .ex4 library