![MQL5 - Language of trade strategies built-in the MetaTrader 5 client terminal](https://c.mql5.com/i/registerlandings/logo-2.png)
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
Where is this conclusion argued ?
My posts (see the search engine) and opinion are exactly the reverse : in general, it's not worth the trouble to implement indicators directly in the EA.
If I understood well what you meant with "calling indicators through OOP" (I guess: creating objects in your EA from a class that allows you to get indicator values as you would with an indicator handle), yes you can. There's nothing special about the calculations that are done in an indicator, you can perform them anyway. However, instead of calling iCustom/IndicatorCreate, CopyBuffer and IndicatorRelease, you would need to copy rates, send them to your object, and handle the updates of your values correctly in your object... that's much more complicated, prone to bugs and difficult to debug in my opinion.
In the past it used to make sense in some cases because of how terribly slow the deinitialization of indicators was in MT5 (and many other errors that were a direct consequence of that), but that issue was fixed a while ago. Nowadays, using objects is not worth it as far as I know (unless you have that many or that much complex indicators in your EA that your terminal can't handle all the calculations of previous candles values without a hit in performance, you only need very recent values in your logic, and the calculations of those recent values aren't recursive so they don't get altered as it could happen with an EMA)
loool
He will still not like your answer.
loool
He will still not like your answer.
loool
He will still not like your answer.
No that was a nice answer. The poll is still going to shit though 😂
But it is not real OOP, why does it still contain iCustom, real OOP doesn't need iCustom
This is the whole problem. The customer has a misconception about what OOP is. Because of this, he drew up technical requirements that are misleading.
It would be correct to indicate in the specification that the advisor should calculate indicator values without using iCustom. Regarding OOP, it is not clear to me why he requires using OOP. It would be understandable if he gave the interface/base class that needs to be implemented and described the implementation requirements.
😄😄😄
This is the whole problem. The customer has a misconception about what OOP is.
A person who knows programming would do something like this (In this case, the requirement to use OOP appears logical):
he gave the interface/base class that needs to be implemented and described the implementation requirements
And a person who does not understand programming cannot make a conclusion about whether this is real OOP or not.
Your customer made technical specifications that were misleading because the terms he used did not mean what he intended them to mean.
[EDIT]
But, to be honest, the technical requirements initially look strange and indicate that something is wrong here. Therefore, at least part of the blame lies with you because you agreed to fulfill strange vague requirements that can now be interpreted in any way