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
But you can't program with OOP in MQL4, so it's still more popular.
I've already shown my code, and I'll show it again:
This is the trade processor interface - it's exactly the same for both MT4 and MT5.
The user just gets this interface - and he has all the possibilities for trading actions. You don't even have to know whether it's on MT4 or MT5. You need to buy - call the function Buy, which will fill the ticket of the open trading component (for MT4 it is an order, for MT5 it is a position), and it will return the return code of the trade server.
You don't even need to think about the difference between MT4 and MT5 protocols - the interface provides everything you need.
These are all OOP capabilities.
I've shown my code before and I'll show it again:
This is the trade processor interface - it is exactly the same for both MT4 and MT5.
The user simply receives this interface - and he has all the possibilities for trading actions. He doesn't even need to know whether he is on MT4 or MT5.
And it's all thanks to OOP.
Are there any examples of use for typical cases?
If your theory was that MQL4=MQL5, then MQL4 could be run on MT5 and vice versa.
Do you have examples of usage for typical cases?
Well, let's say, here is my function sending request to change TP-SL to trade processor:
First, EA part objects - form trade action requests (here, one such request is to change TP-SL). After that, ProceedRequestInto() function is called for all requests to send information about a trade action to the trade processor.
The trade processor itself is an object of the following class:
That is, depending on the platform - CTradeProcessor class is inherited either from CMT5TradeProcessor class or from CMT4TradeProceccor class.
Of course, all this could be done without OOP, with help of switches and ifdefs. But to my mind, OOP-approach is more convenient and clear, and the main thing is that it allows to isolate entities from each other and to get rid of mass of global variables.
By the way, another "echo of OOP" is just in the additional functions of working with the pending orders. The trade processor - works with ticket of deals, which is inconvenient - the reference to the ticket in MT4 and MT5 is different. That's why there is the common class COrderInfoCore - descendant of the order interface. It is much more convenient to pass to the processor just a pointer to this object. Accordingly, this way we bypass the platform-dependent fragments.
Well, let's say, here is my function sending request to change TP-SL to trade processor:
First, EA part objects - form trade action requests (here, one such request is to change TP-SL). Then ProceedRequestInto() function is called for all requests to send information about a trade action to a trade processor.
My code runs completely unchanged on MT4 and MT5.
Why run in different terminals?
I think it's too complicated to understand what's really going on inside... And without an understanding of how it works, I don't think anyone will use it... Isn't it easier to write a separate version for MT5 and plug it in when needed?
George Merts:
But, in my opinion, OOP approach is much more convenient and clear. And most importantly - it allows to isolate entities from each other, and get rid of masses of global variables.
That's the point, having isolated everything from everything, it will be much more difficult to deal with such code, not to mention the impossibility of adequate debugging of code when you need to know current values of all required variables...
Why run in different terminals?
Because my main account is open on MT4, and my strategy tester is much better on MT5.
It is a common request of the clients in Freelance - "it must work on both MT4 and MT5" - it means that there is a reason for that. I myself do not see the reason for working in Freelance, but you can ask those who work there why customers request crossplatform.
Why do we need to "understand what's actually being done inside"? There is a fixed interface that performs an action, regardless of platform - that's what we use. And what is there, at a low level - what difference does it make ?