Discussion of article "Library for easy and quick development of MetaTrader programs (part XVII): Interactivity of library objects" - 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
Order properties can be obtained. Position properties can also be obtained. From the properties of positions you can get its entire history - from the trade order to closing. Each deal of a position allows you to know the order, which was used to get the deal. In general - the whole history of any position can be easily obtained, and all orders and deals can be found in it.
great!
this is a necessary material for me to study, I know that you know how the MT5 order system is organised (unfortunately, there are practically no people with this information on this forum).
please tell me the number of the article where I can find this material.
great!
this is a necessary material for me to study, I know that you have knowledge of how the MT5 order system works (unfortunately, there are almost no people with this information on this forum)
please tell me where I can find this material.
The first part tells about the general structure of the library (it remains almost the same as described, but undergoes refinements in the process of narration).
The second part starts creating a collection of orders and positions. In the fourth part, trading events begin to be discussed.... And all this stretches up to the ninth article, where the finalisation to compatibility with MQL4 begins.
Surrealism, Peter, is only in your head - here everything is structured and easily accessible....
You have gone into too deep philosophy in your elaboration, forgetting about the practicality of building such an "ideal scheme". Here are some quotes:
"Today we will go a little further, and endow this object, and thus - and any other objects of the library, the ability to set which properties will be controlled externally for their changes, the size of the controlled change and the size of the controlled level of the value of the property of the object. "
Consider this: "...thesize of the controlled change and the size of the controlled level of the object property value." What is " the magnitude of the controlled level of the object property value"? That is, 1. There is a property of the object. 2. The property has a controlled level of value. 3. The controlled level has n number of values and .... 4. There is also the size of the controlled change, which can vary. Doesn't it seem like an overkill in the number of entities? This is only a drop in the sea of philosophy in your article.
Further:
"So here it is suitable to control the change of states of object properties: integer and real - their list for each inheritor class is unique and will represent the event identifier. We will also need to take into account the direction of change of properties - an increase or decrease in the value of the property - let's call it the cause of the event, and the value by which the property of the object was changed. The event identifier, its cause and the value of the change will be recorded in a simple class of the base event of the object and stored in the list of simultaneously occurred events. "
Let's list the entities found:
1."Change of states of properties of the object". That is, there are properties and there are property states of the object. Ostensibly, by the state of a property is meant its value. But the value can be represented as an object whose property will be its type. Which you did by dividing the property states (value) into integer and real. Then, there was a reference to some unique list (I don't know when exactly it appeared) of integer and real property states of the objects of the class's successors.
2."Direction of change of properties" Well, it is clear - increase/decrease of value is the direction of change. BUT WHY IS THE DIRECTION OF CHANGE THE CAUSE OF THE EVENT? In principle, the change of direction is the cause of the event, not the direction itself.
3. " We will write the event identifier, its cause and the value of change into a simple class of the base event of the object and save it in the list of simultaneously occurred events."
Well, this is amazing. There is an event identifier. Good. There is the cause of the event and the amount of change in something (just the amount of change. abstractly), good. BUT THERE'S A SIMPLE BASE EVENT CLASS! I repeat: A simple base event class! Abstraction from abstraction. The event, as a thing-in-itself, has found its class! But it's only an object event. So there can be property events, value level events (property states).
And the cherry on the cake:
4."and store in the list of concurrently occurred events." That is, there is also a list of concurrently occurred events. And why not... But, then there should be a list of events with levels of controlled time difference relative to other events. We can add that, can't we?)
This is only a small fragment of a larger article in the series. Do you think it's very simple? )) I will study your articles as an interesting programme experiment of a person who was supposed to become a philosopher by vocation.))
You have gone too deep into philosophy in your elaboration, forgetting the practicality of constructing such an "ideal scheme".Here are a few quotes:
"Today we will go a little further, and endow this object, and thus - and any other objects of the library, the ability to set which properties will be controlled externally for their changes, the size of the controlled change and the size of the controlled level of the value of the property of the object. "
Consider this: "...thesize of the controlled change and the size of the controlled level of the object property value." What is " the magnitude of the controlled level of the object property value"? I mean, 1. There is a property of the object. 2. The property has a controlled level of value. 3. The controlled level has n number of values and .... 4. There is also the size of the controlled change, which can vary. Doesn't it seem like an overkill in the number of entities? This is only a drop in the sea of philosophy in your article.
Further:
"That's why it is suitable to control the change of states of the object properties: integer and real - their list for each inheritor class is unique and will represent the event identifier. We will also need to take into account the direction of change of properties - an increase or decrease in the value of the property - let's call it the cause of the event, and the value by which the property of the object was changed. The event identifier, its cause and the value of the change will be recorded in a simple class of the base event of the object and stored in the list of simultaneously occurred events. "
Let's list the found entities:
1."Change of states of properties of anobject". That is, there are properties and there are states of properties of the object. Apparently, the state of a property means its value. But the value can be represented as an object whose property will be its type. Which you did by dividing the property states (value) into integer and real. Then, there was a reference to some unique list (I don't know when exactly it appeared) of integer and real states of properties of objects of class successors.
2."Direction of change of properties" Well, it is clear - increase/decrease of value is the direction of change. BUT WHY IS THE DIRECTION OF CHANGE THE CAUSE OF THE EVENT? In principle, the change of direction is the cause of the event, not the direction itself.
3. " The identifier of the event, its cause and the value of the change will be recorded in a simple class of the base event of the object and stored in the list of simultaneously occurred events."
Well, this is amazing. There's an event identifier. Good. There is the cause of the event and the amount of change in something (just the amount of change. abstractly), good. BUT THERE'S A SIMPLE BASE EVENT CLASS! I repeat: A simple base event class! Abstraction from abstraction. The event, as a thing-in-itself, has found its class! But it's only an object event. So there can be property events, value level events (property states).
And the cherry on the cake:
4."and store in the list of concurrently occurred events." So there is also a list of concurrently occurred events. And why not... But, then there should be a list of events with levels of controlled time difference relative to other events. You can add it, right?)
This is only a small fragment of a larger article in the series. Do you think it's very simple? )) I will study your articles as an interesting programme experiment of a person who was supposed to become a philosopher by vocation.))
How complicated everything is in your head :D
You have invented complexity for yourself.
Maybe I am very bad at explaining things, but....
We have a price. Price is a property of a symbol. Price has the ability to change. Either in the direction of its increase or in the direction of its decrease. The size (the amount by which the price increased or decreased we have the right to control and set - this is "the size of the controlled change"). And also the price can cross the set (controlled by us in the programme) value, which we can also set - this is "the size of the controlled level of the value of the property of the object".
Is it clear?
We have a spread. Spread is a property of a symbol. The spread has a possibility to change. Either towards its increase or towards its decrease. Size (the amount by which the spread has increased or decreased we have the right to control and set - this is "the size of the controlled change"). And also the spread can cross the set (controlled by us in the programme) value, which we can also set - this is "the size of the controlled level of the value of the property of the object".
Is it clear?
These are just two different properties of one and the same object - a symbol. Let it be the current one. Although they can be properties of different symbols - objects are different, but properties of the same type of objects are the same. And the control over the same properties of the same type of objects is the same. Absolutely. Because it is executed in one basic object, from which all objects inherit - it is their foundation. And it is the same for all objects - not the same for all, but the same.
So: different properties of one and the same object can be controlled in different ways - you can create control methods for each of the properties - write a control for each property and rest on that. Or you can write one method to control absolutely any properties of any object and not write tonnes of code for each property, but write just one method for all of them at once.
And after the object has recorded its events in the list of its own events (these events are called basic events - absolutely every object has them), then the programme sends events - full-fledged events, which the user can already process and make a decision, then to know in the programme from which object the event came, and what kind of event it is, we need to describe it. And describe it unambiguously. There are three parameters for this purpose:
Bottom line: we know for sure that (1) it was the symbol that sent us the event, (2) - the property became less than the controlled level, and (3) - this property is the Bid price.
Complicated? Don't make it up - it's simple.
And then, bam:
We have a trading permit. Trading permission is a property of an account. Trading permission has the ability to change. And by several values. Size (the value to which the trade permit has changed we have the right to control and set - this is "the size of the controlled change"). And also the permission to trade can cross the set (controlled by us in the programme) value, which we can also set - this is "the size of the controlled level of the value of the object property", for example - there is a ban on opening positions to buy.
And after all, this - a completely different object, will send to the programme the same codes that were sent by the symbol from which the event is built. And all this will be done by one and the same method of one object-foundation of all objects.
Is it clear?
And in general - everything is described in the articles. But you seem to be just trolling? :) To ask such questions, you should read it with the attitude "how everything is running here", and not delve into the simple organisation of data.
...Complicated? Don't make it up - it's simple....
A classic mistake of authors of articles is to think that if the material is clear to them, it is clear to everyone). But, it is not so.
Your explanation now put a lot of things in place, and if you had put it in the article (say at the beginning), further would be clearer. And I'm not trolling you. Just when the flow of abstraction (though justified and necessary) is not mixed with specifics and when they do not refer to and explain each other, (abstraction begins to prevail), opinions like the ones I expressed above arise.
S.F. In general, as I understood, you are trying to generalise and collect in this library everything that is in algo-trading.
A classic mistake of authors of articles is to think that if the material is clear to them, it is clear to everyone). But, this is not the case.
Your explanation now put a lot of things in place, and if you had put it in the article (say at the beginning), it would have been clearer. And I'm not trolling you. It's just that when the flow of abstraction (albeit justified and necessary) is not mixed with specifics, and when they don't refer to and explain each other, (abstraction starts to dominate), opinions like the ones I expressed above arise.
S.F. In general, as I understood, in this library you are trying to generalise and collect everything that is in algo-trading.
All I want to do is to give people a tool for easy creation of programmes of any algorithm complexity.
The library simply takes care of all the routine that one always has to write by oneself.
The user will only have to "ask a question - get an answer - process it"
And the library itself will remind about the events. I.e., in principle, it will be enough just to see what kind of event, and from what object came, and then - according to the conceived logic to process it.
The user can ask how the last position was closed - he will get an answer - then according to his logic....
Or he can ask for the last closed position and then he can parse it by its components - the library allows to get all the data about any position that the user has taken from the library data.
Or you can do it this way: the programme receives an event that such a position was opened/closed on such a symbol, or such an order was set/deleted. If the programme has to track someone else's interference in trading, this message will tell about it - the programme did not send any requests, but the environment has changed - it must be processed.
In principle, you can think up and implement a lot of things - I try to give all possible tools for this. Automatic ones - everything is already there, and you don't need to invent them yourself - just get them ready and carefully given ;).
A classic mistake of authors of articles is to think that if the material is clear to them, it is clear to everyone). But, it isn't.
...And the classic mistake of some readers is that they do not read, but immediately ask questions :)
If you start reading from the first article, there will be no such questions, because the whole "philosophy" is there, and it is explained.
Artem, thank you!
Don't, don't stop, keep writing - it turns out great.
I read with interest your discussion with Peter. Very correct and to the point.
I wrote a letter to AMD, - I am not involved in designing and manufacturing processors, but, guys, you have made a nonsense of the 8nm process....
I'm waiting for a reply
You have gone into too deep a philosophy in your elaboration, forgetting the practicality of constructing such an "ideal scheme." ... .
The philosophy here is this: induction (from particular to general) or deduction (from general to particular).
Artyom uses the inductive method of presentation.
Chief: Well, Gleb Georgievich, there's a bullet. Your judgement...
Zheglov: Well, what do you say, "intelligence"?
Sharapov: Well, the bullet is like a bullet, ordinary, pistol bullet....
Zheglov: Yes, it would be good to find a casing.
Chief: It's better to look at the weapon itself.
Zheglov: That's right. Well, it means this: a bullet fired from an imported weapon of 6.35 calibre of the Bayard or, say, Omega system.
Chief: What does that mean?
Zheglov: The bullet, Sergei Ipatich, the bullet. Six left verical rifling cuts, that's it - the handwriting is quite "independent".
Chief: What do you say to that? Judging by the markings, the cartridge case is ours, domestic.
Zheglov: Yes. Where was it found?
Chief: Where it should be. To the left of the body. The reflector worked properly.
Zheglov: Yes, the casing is ours. Hmm. Well, we'll put it in the riddle. We still have to look for the weapon. Nadezhda, do you know if there were any weapons in the house?
Nadezhda: I don't know.
[Weiners. The Age of Mercy]
Artem, thank you!
Don't, don't stop, keep writing - you're doing great.
I read with interest your discussion with Peter. Very correct and to the point.
I wrote a letter to AMD, - I am not involved in designing and manufacturing processors, but, guys, you have argued nonsense about the 8nm process....
I'm waiting for a reply
Hi, Alexei.
Why stop at the beginning of the journey? All the stops for thinking have already been made - now only forward on the bumps ;)
Well, how did AMD answer you ?