Discussion of article "Library for easy and quick development of MetaTrader programs (part XXX): Pending trading requests - managing request objects"
Good afternoon,
Thank you for the work you have done
A small request: I honestly went through the articles (primarily to increase my knowledge), but due to the length of the article cycle and the need to deal with other projects I have to go back and revisit past articles to understand the changes. The project has grown and as such - if possible, in a future article go back and illustrate the resulting library structure today.
Regards and thanks in advance
Good afternoon,
Thank you for the work you've done
A small request: I honestly went through the articles (primarily to increase my knowledge), but due to the length of the article cycle and the need to deal with other projects I have to go back and revisit past articles to understand the changes. The project has grown and as such - if possible, in a future article go back and illustrate the resulting library structure today.
Regards and thanks in advance
I'll try to figure out how to illustrate a fairly simple structure somehow. It is very simple, and at the same time - has a lot of links between different classes of the library.
Everything that is created - everything is accumulated in CEngine - from this object at the moment there is access to all classes of the library (and there will be another access point - through the class of user functions, but already to be completed). But for now there is access only to those methods of all created classes, which are necessary at the moment.
The classes themselves use pointers to each other to be able to use the data of one class in another. And if you start showing all these relationships, you can get even more confused. And if you show all the base objects, which are inherited by many classes and lists within classes, and also show where they all run in the timer - it will be a mess.
That's why it's much easier to simply present the structure of one class, and all other classes are identical to this structure. And it is very simple, but absolutely insufficient for displaying the structure of the whole library and its interrelations.
And one more thing - the library is gradually expanding, but again within the framework of the concept of building library objects stated at the very beginning. So it is enough to understand its structure once, and then it will be quite simple.
But of course I will be thinking (and I am already thinking) how to show everything in a simpler and more accessible way.
Artem, good afternoon. Your work is invaluable! Thank you for the opportunity to develop and the time you spend so that people like me can save it qualitatively.
I have a suggestion: should we publish a repository with your libs on github? What it would do:
- Well, a version control system, of course.
- An opportunity for everyone to participate in the development of the DoEasy library.
- The ability to quickly search through the code and access the most up-to-date version at any time.
For example, while studying the library, I found and fixed some bugs and optimised some code. And in such a case I could now send you a special request within the framework of the version control system, by which you would decide whether to accept my improvements into the current version of the library or not.
You are doing a great job, and we together (there are many people like me) could invest our own time for the common good in order to improve DoEasy. I am ready to help in realisation of the proposed.
Artem, good afternoon. Your work is invaluable! Thank you for the opportunity to develop and the time you spend so that people like me can save it qualitatively.
I have a suggestion: should we publish a repository with your libs on github? What it would do:
- Well, a version control system, of course.
- Opportunity to participate in the development of the DoEasy library for everyone.
- The ability to quickly search the code and access the most up-to-date version at any time.
For example, while studying the library I found and fixed some bugs and optimised some code. And in such a case I could now send you a special request within the framework of the version control system, by which you would decide whether to accept my improvements into the current version of the library or not.
You are doing a great job, and we together (there are many people like me) could invest our own time for the common good in order to improve DoEasy. I am ready to help in realisation of the proposed.
Hello. Thank you for your feedback.
At the moment it's too early to talk and think about the repository - the library is under active development, and until I create and publish everything I've planned, I don't want to deviate from the plan. And its numerous fixes and revisions by third-party users will only distract the author from following the plans.
But it is better to report about the found errors and ways of their elimination directly in discussions of those articles where errors were found - it will just help the development of the library and elimination of the found errors.
When compiling the TradingControl.mqh file, two errors occur:
'CTrading::OpenPosition<double,d...' - cannot access private member function TradingControl.mqh 328 21
see declaration of 'CTrading::OpenPosition<double,double>' Trading.mqh 146 24
'CTrading::PlaceOrder<double,double...' - cannot access private member function TradingControl.mqh 344 18
see declaration of 'CTrading::PlaceOrder<double,double,double,double>' Trading.mqh 156 26
These methods are in the private section of the CTrading class. The errors go away if you move them to the public section of this class. But in the attached files (and as I understand, they are working) these methods are also in the private section of the CTrading class, and these two errors occur when compiling the TradingControl.mqh file.
Artyom, then how does it work for you? Either there is an error here or I misunderstand something.
P.S. I have downloaded the attached files for the next part - 31, and there too these methods are located in the private section of the CTrading class and also these two errors occur when compiling.
Two errors occur when compiling the TradingControl.mqh file:
'CTrading::OpenPosition<double,d...' - cannot access private member function TradingControl.mqh 328 21
see declaration of 'CTrading::OpenPosition<double,double>' Trading.mqh 146 24
'CTrading::PlaceOrder<double,double...' - cannot access private member function TradingControl.mqh 344 18
see declaration of 'CTrading::PlaceOrder<double,double,double,double>' Trading.mqh 156 26
These methods are in the private section of the CTrading class. The errors go away if you move them to the public section of this class. But in the attached files (and as I understand, they are working) these methods are also in the private section of the CTrading class, and these two errors occur when compiling the TradingControl.mqh file.
Artyom, then how does it work for you? Either there is an error here or I misunderstand something.
P.S. I have downloaded the attached files for the next part - 31, and there too these methods are located in the private section of the CTrading class and also these two errors occur when compiling.
This became so after a recent update. Try to make them in a protected section so that they cannot be accessed from outside. Public ones are too bad
This became so after a recent update. Try making them in a protected section so they can't be accessed from outside. Public is too bad
Ok, I'll do that.
One more question: there are methods in the public section ClosePosition, PlaceBuyStop, PlaceBuyLimit, etc. Is it not critical for them that they are in the public section?
- Free trading apps
- Over 8,000 signals for copying
- Economic news for exploring financial markets
You agree to website policy and terms of use
New article Library for easy and quick development of MetaTrader programs (part XXX): Pending trading requests - managing request objects has been published:
In the previous article, we have created the classes of pending request objects corresponding to the general concept of library objects. This time, we are going to deal with the class allowing the management of pending request objects.
Initially, I wanted to make an independent class for managing pending requests featuring all the necessary methods. But it turned out that the main CTrading class of the library and the created new class of managing pending requests are so interrelated that it would be much easier to let the new class for managing pending request objects be the descendant of the main trading class.
The entire management of pending request objects is performed in the class timer, therefore we make the base trading class timer virtual, which means the timer of the pending request management class is to be virtual as well. Then everything that relates to the base trading class timer is set in the class timer, while everything that should work in the class for managing pending request objects is set in the timer of that class.
Apart from the class for managing pending request objects, we are going to create a small class to arrange a pause to avoid using the Sleep() function which stops the program execution for a delay time. With the pause object, we will no longer depend on ticks which means we will be able to test a code requiring waiting on weekends. The pause is to be controlled in the timer.
Author: Artyom Trishkin