Is it possible to call custom indicators through OOP without iCustom and CopyBuffer? - page 2

New comment
 
Alain Verleyen #:

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.

I was referring to this discussion:


Should have linked it in the first post.
 

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)

 
Dominik Egert #:
I guess the answer is sort of. At least that would represent my opinion.

If the indicator declares the OnCalculate function with the keyword export, you could load the indicator .ex5 file as a library.

But your indicator code needs to be adjusted heavily to actually work.

So, with source code available, yes.

Without source code, you can only use iCustom as possible solution.

loool
He will still not like your answer.

 
Alain Verleyen #:

loool
He will still not like your answer.

No that was a nice answer. The poll is still going to shit though 😂

Alain, can I use some specifics of a former job in a discussion if I keep it anonymously? I know there is a rule to not post screenshots of a freelance discussion but I can't find the exact rule.
 
Alain Verleyen #:

loool
He will still not like your answer.

Haha. As I was reading your reaction, I thought, you're right. And actually my answer is more on the theoretical side, than on a practical one...
 
Tobias Johannes Zimmer #:
No that was a nice answer. The poll is still going to shit though 😂

Alain, can I use some specifics of a former job in a discussion if I keep it anonymously? I know there is a rule to not post screenshots of a freelance discussion but I can't find the exact rule.
Ok, but where do you want to get to, with this poll?

I still don't understand why you created that poll. I mean, maybe there is some second thought on this, and I currently cannot see what you are actually aiming at.

Could you enlighten me a bit on that?
 
Dominik Egert #:
Ok, but where do you want to get to, with this poll?

I still don't understand why you created that poll. I mean, maybe there is some second thought on this, and I currently cannot see what you are actually aiming at.

Could you enlighten me a bit on that?
I had a job and the customer wanted "MQL OOP". I linked him to this article and said that I was going to create a class from his indicator analogous to the article.

I even send him the source code of a former private project of mine beforehand where I did the same with a smoothed RSI to give him complete knowledge about the proceeding and it seemed he was fine with that too.

Then when I finished the job in the before mentioned manner he said: "But it is not real OOP, why does it still contain iCustom, real OOP doesn't need iCustom. This is just a mix of OOP and functional programming."

I just thought that maybe this is a thing where an open discussion would help because I remember that before I was aware of what the standard library is, I kept thinking the same: That the mql functions were built on the standard library and not the other way around.
 
Tobias Johannes Zimmer #:
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.

 
Vladislav Boyko #:
😄😄😄

This is the whole problem. The customer has a misconception about what OOP is. 

I know that's what I was trying to prove with the poll but it doesn't look so good 😂

 

A person who knows programming would do something like this (In this case, the requirement to use OOP appears logical):

Vladislav Boyko #:
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

123
New comment
Reason: