Discussion of article "Library for easy and quick development of MetaTrader programs (part XXVII): Working with trading requests - placing pending orders" - page 3
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
It is not me who does not want to communicate on the topic, but you have not understood the essence of this topic.
You have decided that I don't understand that each type of deferred query needs its own solution. All requests have their own properties and a common solution is impossible. One solution for orders is one solution, another for repeated request of some data. In the last two articles we are working on a solution for orders. The next one will be about it too. My opinion is that it is too long.
3 articles for solving a pending request ONLY for orders, two of which do not complete anything.... While in fact (not in form) the solution for pending order request is quite easy.
You decided that I don't understand that each type of pending query needs a different solution. All queries have their own properties and a common solution is impossible. One solution for orders is one solution, another for repeated request of some data. In the last two articles we are working on a solution for orders. The next one will be about it too. My opinion is that it is too long.
3 articles for solving a pending request ONLY for orders, two of which do not complete anything.... While in fact (not in form) the solution of the pending order request is quite easy.
The "impossible" part is a bit hasty.
Exactly, it's impossible. Different object-queries - different properties. You can't put all the properties in one query object.
I just wonder how a simple task can be solved for a month and a half in three articles. If this programming method is considered "efficient", then I'm glad I program differently.
It is impossible to trace all of the EA's calls to the server.
I ask, because the solution to the problem of repeated sending of failed orders (obviously) does not require complication and is solved simply.
If orders are not sent using library methods, then all the trading logic must be written independently. The library provides an opportunity not to do this, but does not force you to do everything through its functionality.
In such a situation, the library cannot manage trading functions that are not its own. But it will be able to report the fact of a successful trade request sent through third-party functions.
Use the functionality of the library, where there is a reaction to errors returned by the server and their adequate processing.
What do you see as a handler of server return codes?
Exactly, it's impossible. Different query objects - different properties. You cannot insert all properties in one object-query.
I just wonder how a simple task can be solved in three articles for a month and a half. If this programming method is considered "efficient", then I'm glad I program differently.
The objects are pending trade requests. All information about any trade requests is stored in a single structure for all requests - MqlTradeRequest.
Are you trolling?
In fact, I describe the concept. Step by step. In articles (I write texts myself, I check for errors three or four times, and I miss some of them). I voice the content of the concept in articles, logic and functionality, show how to do it. At the same time, I think through various options beforehand, and a large part of them are thrown in the bin - i.e., in fact, I write code three or four times more than there is in the articles. Sometimes I completely rewrite all the code from scratch, and according to different principles. Then I test everything in the tester and demo - what is described in each article. And then I miss some bugs and correct them later in the next articles.
If the code works from the first time - it means that there is a bomb buried in it, and expect a big surprise in the future.
I am surprised that you write everything for yourself in an hour. No checks, no testing, and just as long as it moves :)
I really want to understand what you consider simple here. Why don't you want to understand that this is a part of future functionality of other parts of the library, and everything in advance should be linked "in your mind" with what is not yet there, but planned?
I don't set a task to do it once and leave it to float. I have a different task - to think through how everything will be interconnected further. It takes time and a certain approach. If it's difficult for you, well... Then it's complicated.
...
And what do you see as the server return code handler?
I will show you a short and effective solution.
1. Declare a global variable: string Del_req;
2. Write the void Delayed_request() function. The function will be called from OnTimer() once per second (if Del_req != NULL).
3. Add the parameter int delayed_request_ID = 0 to each trading function that sends an order.
4. Each trade request returns a server response. If delayed_request = 0 (not a repeated call from Delayed_request() ) and the server response requires repeating the request, trade functions write all call parameters to the Del_req variable (through two separators - delayed_request_ID and parameters) and at the end of the line add the number of required attempts (for example, 10).
5. The Delayed_request() function checks the Del_req string once a second. If the string is not NULL, the function puts it into an array and loops through it to find the substring of the call, finds it, extracts it from the total string, splits it, looks at the type of call and passes the parameters to the required trade function along with the delayed_request_ID. Next, it looks at the call counter and decrements it by one. If the counter is zero after subtracting one, it erases the entire call substring from the total Del_req string.
6. If the trade function accepts a call with delayed_request_ID and the request to the server was successful, it erases the call substring from the common Del_req string (finds it by delayed_request_ID).
All this can be done in one day and can be applied not only to trade requests, but to any requests.
ZY. No trolling, I am really surprised by the non-obviousness of simple solutions for mature programmers.
I'll show you a short and effective solution.
1. Declare a global variable: string Del_req;
2. Write the void Delayed_request() function. The function will be called from OnTimer() once a second.
3. Add a parameter int delayed_request_ID = 0 to each trading function that sends an order.
4. Each trade request returns a server response. If delayed_request = 0 (not a repeated call from Delayed_request() ) and the server response requires repeating the request, trade functions write all call parameters to the Del_req variable (through two delimiters - delayed_request_ID and parameters) and at the end of the line adds the number of required attempts (e.g. 10).
5. The Delayed_request() function checks the Del_req string once a second. If the string is not NULL, the function puts it into an array and loops through it to find the call, finds it, extracts it from the total string, splits it, looks at the type of call and passes the parameters to the required trade function along with the delayed_request_ID. Next, it looks at the call counter and decrements it by one. If the counter is not zero, Del_req changes the call counter in the call string to a value smaller by one, if it is zero, it erases the entire call string from the total Del_req string.
6. If the trade function receives a call with delayed_request_ID and the request to the server was successful, it erases the call substring from the total Del_req string (finds it by delayed_request_ID).
All this can be done in one day and can be applied not only to trade requests, but to any requests.
ZY. No trolling, I am really surprised at the non-obviousness of simple solutions for mature programmers.
To deliberately push brakes into methods?
And what is the difference between the proposed method and the one that is being done? Apart from the fact that you will have to work through expensive functions of working with strings? Conceptually nothing. That's why - it will be as it is intended. Moreover, what is being done, and you don't know it yet, will be used to extend the functionality of working with deferred queries.
Consciously pushing the brakes in methods?
And what's the difference between the proposed method and the one that's being done? Apart from the fact that you will have to work through expensive functions of working with strings? Nothing. That's why - it will be as it is intended. Moreover, what is being done, and you don't know it yet, will be used to extend the functionality of working with deferred queries.
Do as you see fit. It is your creativity. I expressed my opinion.
And there are no brakes. Pending requests are still sent once a second.
The difference is that pending requests don't turn into full-fledged Objects and thus don't drag a lot of code behind them.
Do as you see fit. It's your art. I gave my opinion.
And there are no brakes. Pending requests are sent once a second anyway.
Why are they sent once a second? To flood the trading server?
It differs by the fact that pending queries do not turn into full-fledged Objects and thus do not drag a lot of code behind them.
And I just need full-fledged objects to implement what I'm planning to do next. But you don't know about it yet, and you are trying to offer ineffective ways of solving a small part of the task for further work. And here everything is linked together, and the general concept is the same - the other things planned in the future depend on this small part.
Anyway, thanks for your opinion - any opinion is useful and makes sense.
ZY. And, yes - it is not terrible to write a working, extensible and compatible piece of code rather than to constantly rewrite previously thoughtlessly written incomplete solutions for the next tasks.