Discussion of article "Library for easy and quick development of MetaTrader programs (part I). Concept, data management and first results" - 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
Artem, don't pay attention to the neo-devotees, please. Let them scream. You are doing a good job. I have a question - is there at least a rough schedule for the next articles in this series? For example - once a week, once a month, quarterly .... ???
The second article is ready - waiting for publication. The third is in development. I plan not to delay the release of new parts, as they are all interconnected, and each part is a continuation and expansion of previous parts. I plan to release a series of articles. As a result, there will be a library, having connected it, the user will immediately get an automated collection of necessary data, a wide range of tools for using the available data in his programmes. There will be given and explained access to necessary methods of library classes, or simple habitual use of usual functions for those who are not familiar with classes - there will be a large set of library functions, as well as access to data by means of structures. The user will not have to do any data retrieval and processing - he will only need to request the data he needs in a "question-answer-application" style.
For example: query: when was such a pending order deleted? answer: then. Or: query: you need data on the last closed position, answer: a filled structure with all position data is returned. Or: you need to delete an order clicked by the user, the answer is that the order was deleted. Or: we need a ticket of a position with the smallest open price on the symbol EURUSD and with the magick 12345, the answer will be returned the price of this order and the filled structure with all the data of this position.
Queries, of course, are made by functions. As an example (hypothetical): GetLastClosePosition() - returns a structure with filled fields about the last closed position, GetLastClosePosition("USDCAD") - returns a structure with filled fields about the last closed position on the symbol USDCAD, etc.
But it will be possible to address classes directly and get pointers to lists, from which to take the necessary data independently.
And so on, etc., etc.
For example: query: when was such a pending order deleted? answer: then. Or: request: we need data on the last closed position, the answer: a filled structure with all position data is returned. Or: you need to delete an order clicked by the user, the answer is that the order was deleted. Or: we need a ticket of a position with the smallest open price on the symbol EURUSD and with the magick 12345, the answer will be returned the price of this order and the filled structure with all the data of this position.
It is expensive to return the structure. For the same reason CopyRates is several times more expensive than CopyClose.
It is expensive to return a structure. For the same reason CopyRates is several times more expensive than CopyClose.
Well, the return of structures is planned as an additional feature at the user's request - purely for convenience. It will be seen further on. In any case - the library is created "on the fly" with a description of the steps of its creation, with making changes. So further it will be seen how to make "not expensive".
However, I have already done it. Now I'm just describing it in a structured way, while at the same time putting everything in order for myself.
And in general - I am used to doing "from simple to complex", but thinking in advance "what's next" - so as not to get stuck in the need to revise the concept, from which no one is immune.
I can't imagine anything more convenient than what the developers have come up with in MT4.
What do you mean by "expensive"???
Costly in terms of resource consumption
Maybe I don't understand something, but so far the proposed way of localisation (translation of messages into other languages) looks wrong. The source code of the library should not change depending on the localisation, and now Russian is written there as the main one? How is it supposed to add, for example, German or French?
So far
For now
If you leave it like this for now, you will have to change a lot of code later, if you redesign localisation. What is the difficulty in connecting strings from "resource" libraries or headers at once?