Discussion of article "Library for easy and quick development of MetaTrader programs (part XXV): Handling errors returned by the trade server" - page 2
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
About the information recorded in the Magic Number value:
you can use a different magik for each group to create different groups. For example, if the advisor's magic number is 123, then the magic number of the first group will be 124, the magic number of the second group will be 125, the magic number of the third group will be 126, and so on.
The library offers a different way of creating different groups - the number of each subgroup is stored directly in the Magic Number value. Then the EA's magic number is also a group identifier, but it is placed in an independent group called MagicID - the EA's magic number identifier. And there are two more groups. Each of them has 15 subgroups. And each of the subgroups can have its own identifier.
This will givemore flexibility when working with groups.
For example: We want to move a grid of pending orders behind the price - add them to group 1 in subgroup 1. Group 1 moves behind the price. Subgroup 1 moves along the MA. Now we want to move some of those orders that move behind the price (group 1) by Parabolic SAR. We give them subgroup 2. Then group 1 moves after the price, but subgroup 1 moves by MA, and subgroup 2 moves by Parabolic SAR.
Orders are triggered, turning into positions - you can set your own groups for modification of Stop Loss, and your own subgroups in this group for modification by different values. Modification algorithms are written in subgroups.
In general - a flight of fancy. You can also use a simple magik, but you will have to invent the logic of tracking different groups yourself.
On the second question:
There is a CSelect class. It is available from the programme, and provides methods of selection and search you are writing about from all existing collections: Account, Event, Order, Symbol.
You can select the objects of each collection into a list based on all criteria. In the created list, you can reselect by refining criteria, you can find the maximum and minimum values for the selection criterion.
However, further on there will be custom functions (much later) for quick and convenient access to all properties of all collections and search in them.
But for now - only through CSelect, and when you need it. The class is static, so access to its methods via ":::" For example, CSelect::ByOrderProperty().
Yes, by the way, there is an example of its use in the programme right in the test EA - for example, in its trailing functions:
I figured out CSelect, but it turns out that I have to make a choice in each place where we need aggregate values: say, I need to calculate the total profit of a grid of positions in order to trailing it, this is one function. And in another I'm, say, adjusting the total take of a grid after opening, or closing one of the orders - and for that I need the total profit and aggregate volume.
And somewhere else I need to make a decision whether to open a new grid or continue the current one - I need to know how many orders I have already opened in this group.
All these values are calculated by one run through the list, which can be selected by a series of CSelects. But since I need them in different places, I would have to start an aggregate construction each time, recalculate at the beginning of a tick and then use them everywhere.
I thought it would be good to add such a construct to the library, with the ability to allocate it by a set of selection criteria, such as symbol, magick (with groups), order type.
And let it collect simple statistics: number of orders, total volume, total profit... a collection of orders, by the way, since we have already selected it.
Otherwise, either to create an auxiliary structure each time, or CSelects and iteration in each place.
I figured out CSelect, but it turns out that I have to make a choice in each place where we need aggregate values: say, I need to calculate the total profit of a grid of positions in order to trawl it, that's one function. And in another, say, I'm adjusting the total take of a grid after opening or closing one of the orders - and for that I need the total profit and aggregate volume.
And somewhere else I need to make a decision whether to open a new grid or continue the current one - I need to know how many orders I already have open in this group.
All these values are calculated by one run through the list, which can be selected by a series of CSelects. But since they are needed in different places, I have to start an aggregating construction each time, recalculate it at the beginning of a tick and then use it everywhere.
I thought it would be good to add such a construction to the library, with the possibility to allocate it by a set of selection criteria, e.g. symbol, magick (with groups), order type.
And let it collect simple statistics: number of orders, total volume, total profit... a collection of orders, by the way, since we've sampled it already.
Otherwise, either to create an auxiliary structure each time, or CSelects and iteration in each place.
And you propose to make the calculations in the library itself heavier? There's already a lot of things to be calculated there.
Why not do what you suggest directly in the EA instead of the library? There's no difference where to calculate it all. But someone needs it (you) and someone doesn't. And why does he need unnecessary calculations?
In order not to count the same thing in different functions every time, you should create global lists in the Expert Advisor, where you can put the information you need everywhere. And in separate functions, and only as needed, take these public lists, and from them get the data necessary only inside the function, and return them.
The library provides a set of data, gives the possibility of selecting this data in any combination, and gives tools for solving tasks that are not quick enough to do from scratch.
And you're suggesting that the calculations in the library itself be weighted down? There's already a lot of counting going on there.
Why not do what you suggest directly in the EA instead of the library? There is no difference where to calculate it all. But someone needs it (you) and someone doesn't. And why does he need extra calculations?
In order not to count the same thing in different functions every time, you should create global lists in the Expert Advisor, where you can put the information you need everywhere. And in separate functions, and only as needed, take these public lists, and from them get the data necessary only inside the function, and return them.
The library provides a set of data, provides the possibility of selecting this data in any combination, and gives tools for solving tasks that are not quick enough to do from scratch.
Well, I propose to make it optional.
To start a "subscription".
But if this idea doesn't seem worthy of consideration to you, I will certainly write the wrapper myself.
Thanks again for what has already been done - and ahead for all that is still in the plans (I here and there meet reservations about plans to continue the development of the library).
Well I suggest counting optionally.
Make a "subscription."
But if you do not find this idea worthy of consideration, I will certainly write the wrapper myself.
Thanks again for what's already done - and ahead for whatever else is in the pipeline (I've seen reservations here and there about plans to continue developing the library)