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
Oh, my God! Is it valid in the history?
papaklass probably meant that OnTradeTransaction returns errors?
If the information in OnTradeTransaction may not be valid, we have to take it from the history to make sure it is valid.
If onTradeTransaction information is not always reliable, we have to take it from the history to make sure the information was processed.
The question is why the hell do we need OnTradeTransaction if we have to take the information from the history anyway? - It only needs it for error checking. The broker rejected the order and we received the answer why it was rejected in OnTradeTransaction and analyzed it.
but why drool over 9 pages?
Please don't be rude! By the way, it's already 10!
And you are within your rights not to read what is written here at all!
C-4, will be processed, of course, but why the need for OnRefresh()?
Many events -> one handler.
Errors from all corners in one pile! :)
It is not the errors that are sent, but the data. Errors may be in the handler, but they are easy to fix because there is only one handler.
That's exactly what I mean. You need event separation.
It is not the errors that are sent, but the data. Errors may be in the handler, but they are easy to fix because there is only one handler.
You don't need to separate events, you need to separate handlers. Events generate data. Each data type handles its own handler. It doesn't matter who received the data, the important thing is that there is a unique handler for each data type.What is not separated here?
And then there are
What's not shared here?
What you suggest (processing of data types) is what MK has at the moment. The OnTradeTransaction handler handles a certain MqlTradeTransaction data type. It's true, they put a lot of things into this data type, i.e. data types corresponding to different events.
I suggest that every event should have its own data and its own handler. As many events, as many handlers. The division of events (opening a position, closing a position, placing an order, modifying an order, modifying a position, etc.). And it is up to the developers to decide what data types to assign to which events.
By the word "handler", I do not mean a system function that receives some event, but some Expert Advisor module that analyzes this event. To multiply the number of functions On... Each of them for its own event - it makes no sense, all the more so it is elementary to create a necessary number of custom handlers. This is how it is done in my case:
It may seem strange that one and the same Event class is passed to completely different handlers which require completely different types of data. For example, OnMouseMove requires a mask of keys pressed on the mouse and its coordinates, OnKeyDown() requires the code of a pressed key, OnOrderChange requires a ticket of the order which was changed and probably an enum describing the exact change. You might think that the event class contains fields for all possible events. But that's not the case. In fact, the object of the event class can't even exist, since its constructor is hidden in the protected area. But its descendants exist in abundance - each descendant to handle only a different event. However, for any event, there is an identifier that indicates what type it belongs to. Knowing this identifier you can perform a safe type conversion from a larger to a smaller type. This is the type of the child that the implicit conversion is performed to when the handler is passed. Let's see how our handlers actually see the event:
Beautiful... It looks like there is only one event, but in fact there could be dozens of them. The event seems to contain almost no information, except its type, but in fact, handlers freely refer to methods known only to them.There are no "external" and "internal" events, just events. And the number of these events is potentially infinite. An event can be anything. An event can contain all kinds of data. By following this philosophy we reach a new, higher level of data abstraction. Why create restrictions in your head, why impose a classification limiting abstraction!
The essential difference between internal and external events is the execution time. Internal events have practically zero execution time, while external events have hundreds of milliseconds to seconds.
Events do not have an execution time. If an event has arrived, it's already executed. This is how asynchronous mode works. So it is wrong to classify events into internal and external because of how fast they are executed. It is correct not to classify at all, but to think very abstractly from concrete implementation.