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
Thank you very much, I am processing the errors, the message comes - wrong price, and I can't figure out what's wrong.
then also add a line
at the beginning of the function - clear error buffer: sometimes it is possible to read "someone else's" error, and this way the error buffer will be cleared at the start of the function.
This is not required, but if the programs for the real world, it is highly desirable to do everything as correctly as possible.
Good luck.
then also add a line
at the beginning of the function - clear error buffer: sometimes it is possible to read "someone else's" error, and this way the error buffer will be cleared at the start of the function.
This is not required, but if the programs for the real world, it is highly desirable to do everything as correctly as possible.
Good luck.
Yes, thank you, that's what I do in real software.
Good people, can you tell me why this function returns 0 even though there are no open orders. Shouldn't there be some kind of error?
Returns the total amount of open and pending orders.
Still writing to order?
-- Using names that start with an underscore and a double underscore is bad form. I'd rather use an underscore at the end.
-- Why _Type_Order string? Unrealistically awkward, I think. Then it would have to be cited. Because if you write "Sell" or "sell" it won't work.
-- If you want to make a mistake, make a mistake:
ERROR = -1;
Better yet.
--
Why break? Suppose, a millisecond ago, the order was closed by TP - why should we not close the rest? This is better:
--
The line is worse than useless -- it is harmful. Is that what you must have meant?
--
That is, if an order suddenly fails to close, "let go of the wheel, close your eyes and start screaming".
There's no need to close the others? No need to try again?
-- Why is there an error return here at all? It would be much more appropriate to return, for example, true if all were successful to close and false if not.
That's all for now.
-- Using names that start with an underscore and a double underscore is bad form. I'd rather have an underscore at the end.
By using names that start with underscores inside functions, I eliminate the risk of variable overriding. Thus, I can use the same names in start() but without underscores, which increases code transparency.
- Why is _Type_Order string? Unrealistically inconvenient, imho. Then it should be given. Because if we write "Sell" or "sell" nothing will work.
You're right, of course. However, using a string increases code transparency and with the amount of code I have at the moment there is no need for an underline. When I come across this problem really, I'll do it, but for now it's not necessary. I simply write SELL or BUY.
You're certainly right, thank you.
The IsTradeContextBusy() function informs only about thread occupancy, IsTradeAllowed() is somewhat broader
That is, if suddenly the order cannot be closed, "let go of the wheel, close your eyes and start screaming"?
yes, for the debugging period it is
Why would there be an error return at all? It would be much more appropriate to return true if everything could be closed and false if not.
Thank you, I seem to have figured out what the error is. I'll check and report back.
The error was as follows:
the bool _Result variable is not initialized, so it will contain false; thus, since none of the conditions have been met, we have not changed the _Result variable, and it already contains false. And the function proceeds to error handling that really didn't occur.
I fixed the function and am posting it here, I think somebody may find it useful.
PS to moderators. I have created such a branch by accident - complete self-tutorial on how to close orders correctly. Maybe it should be renamed as - how to correctly close orders with examples.
PPS Thank you very much to everybody who has taken part. There will probably be more questions.
The error was as follows:
The bool _Result variable is not initialized, so it will contain false; thus, since none of the conditions have been met, we have not changed the _Result variable, and it already contains false. And the function proceeds to error handling that really didn't occur.
I fixed the function and am posting it here, I think somebody may find it useful.
PS to moderators. I have created such a branch by accident - complete self-tutorial on how to close orders correctly. Maybe it should be renamed as - how to correctly close orders with examples.
PPS Thank you very much to everybody who has taken part. There will probably be more questions.
If you look at the CodeBase and carefully read the forum - there are more than a hundred examples of correct order closing, but that does not mean that all branches should be renamed at once. There are enough heroes.
The error was as follows:
the bool _Result variable is not initialized, so it will contain false; thus, since none of the conditions have been met, we have not changed the _Result variable, and it already contains false. And the function proceeds to error handling that really didn't occur.
I fixed the function and am posting it here, I think somebody may find it useful.
PS to moderators. I have created such a branch by accident - complete self-tutorial on how to close orders correctly. Maybe it should be renamed as - how to correctly close orders with examples.
PPS Thank you very much to everybody who has taken part. There will probably be more questions.
IMHO: This function is not clear in its logic. If it is for a tester, it is too much unnecessary, if it is for the real world, the errors should be handled. The returned value has no meaning because you are telling on the external level (on the call level) that the call ended with an error, you are losing the error itself, well, the expert wrote into the log - how does it count?
What would be better: (again, IMHO)
1. Read and save the error number.
2. Split the errors into fixable and non-recoverable. To do this, we should create a handler - those errors, upon appearance of which the order may be closed (a thread is busy, connection failure ..., etc.) should be handled immediately on site. I have done it that way (first the unrecoverable errors, and then those which can be "fixed"):
3. When an intractable error occurs, to return not an error flag, but its number, so that this situation could be handled in an external module. When analyzing the result of an operation:
Good luck.
SZ about break/continue
the question is debatable. If there are still orders, then when a take/stop is triggered the order numbering will change - i.e. the order will still be selected: you select by order number, not by ticket. If the order is not selected, it means that there is no order. Since you do not check the number of orders each time, you will run the cycle blank some number of times.