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

New comment
 
Vladislav Boyko #:

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

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

You are right. But I realised it too late. At some point if you create a job in freelance you have to be aware that you pay somebody else to do something because you can't do it yourself.

I think he wanted to see for himself how "OOP works" and had created a job with that goal. Which I honestly think is a good thing. More people should do that. They just didn't like the outcome
 
Tobias Johannes Zimmer #:
You are right. But I realised it too late.

This is a good experience. Now you understand why technical requirements should not be strange, or those that can be interpreted in different ways. Strange requirements are a sure sign of future problems. It is better to either adjust strange requirements (using clarifying questions) or not take such an order.

 

But strange technical requirements are normal. Only a programmer or business analyst can independently draw up an “ideal” technical specification.

Therefore, a freelancer is first a business analyst who helps the customer draw up the correct technical specifications, and only after that is transformed into a programmer. And all this for 30 dollars😄

 
Tobias Johannes Zimmer #:
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.

OK. now I get your point.

In short, with reference to using iCustom or not:

As already stated, using iCustom is mandatory, if you load an indicator by .ex5, or a built-in indicator of form iXXX. - This is so, because this provides a uniform API usage. - Exceptions to be forced to use iCustom for loading indicators, is only given, if either the indicator was provided with the required code to load it as a library, thus should supply a header file that specifies its inclusion and usage. Or, the source-code is available. - Having the source code still requires individual reimplementation of the calculations done by the indicators functionality in such way, that they can be processed by an EA.

Having such an "environment simulator" inside the EA, such that the functions provided (And mainly speaking of the function OnCalculate) by the indicator source file, can actually be called. - This requires some indicator buffer providing, and other required adoptions such that the function(s) can actually properly work.


Concerning API and the standard library:

Any standard library will always be made up of the basic building blocks of a language (provided by the compiler), like "for", "if" and so on. - Any additional functions are either part of the compiler (assembler code chunks), or they are provided by some other binary code collection. - This code provides the addresses of its functions to the "linking stage of a build process (source to binary). Here the function symbols in your code, generated by the compiler will get replaced with the "addresses" of the functions from the imported binary.

So your (whatever, exe or ex5) executable gets loaded, it loads also the external binary into memory. In this specific case into the application-code memory area. (marked as executable), this is also true for parts of the binary terminal64.exe. (Actually they just get "blended" in by the OS).


So in short libraries, APIs and standard library:

If you write your own library, and you provide functions to be imported by other programs, you actually (sort of) export an "API". While the actual definition of an API narrows a bit what could be called an API. So a simple collection of independent functions is rather in the realm of a "providing or enabling" library, while an API usually involves some type of "synchronizing and exchanging" between two separate "entities".

In conclusion, you could argue, MQL Standard Library actually provides an API, but in this case in "header" form, or in source code, written in the same language as the code utilizing these functions.

MQL-API and what is broadly understood as MQL5, though actually it is not the language, as the language itself is provided by the compiler, functions like ArrayResize or iCustom, or iMA, are functions provided by the implementation of the terminal64.exe in binary form, by blending in this memory into your "process space", your instance of your ex5 code. This is how these functions come to be available to you in your code.

Now if the standard library is written in the same language, and "wrapping" the actual MQL-API into its own concept, this can be considered a wrapper library. - But that is not true for all content. So its a hybrid, a collection of independent functions, and a wrapper API for the MQL-API.

 
Dominik Egert #:

OK. now I get your point.

In short, with reference to using iCustom or not:

As already stated, using iCustom is mandatory, if you load an indicator by .ex5, or a built-in indicator of form iXXX. - This is so, because this provides a uniform API usage. - Exceptions to be forced to use iCustom for loading indicators, is only given, if either the indicator was provided with the required code to load it as a library, thus should supply a header file that specifies its inclusion and usage. Or, the source-code is available. - Having the source code still requires individual reimplementation of the calculations done by the indicators functionality in such way, that they can be processed by an EA.

Having such an "environment simulator" inside the EA, such that the functions provided (And mainly speaking of the function OnCalculate) by the indicator source file, can actually be called. - This requires some indicator buffer providing, and other required adoptions such that the function(s) can actually properly work.


Concerning API and the standard library:

Any standard library will always be made up of the basic building blocks of a language (provided by the compiler), like "for", "if" and so on. - Any additional functions are either part of the compiler (assembler code chunks), or they are provided by some other binary code collection. - This code provides the addresses of its functions to the "linking stage of a build process (source to binary). Here the function symbols in your code, generated by the compiler will get replaced with the "addresses" of the functions from the imported binary.

So your (whatever, exe or ex5) executable gets loaded, it loads also the external binary into memory. In this specific case into the application-code memory area. (marked as executable), this is also true for parts of the binary terminal64.exe. (Actually they just get "blended" in by the OS).


So in short libraries, APIs and standard library:

If you write your own library, and you provide functions to be imported by other programs, you actually (sort of) export an "API". While the actual definition of an API narrows a bit what could be called an API. So a simple collection of independent functions is rather in the realm of a "providing or enabling" library, while an API usually involves some type of "synchronizing and exchanging" between two separate "entities".

In conclusion, you could argue, MQL Standard Library actually provides an API, but in this case in "header" form, or in source code, written in the same language as the code utilizing these functions.

MQL-API and what is broadly understood as MQL5, though actually it is not the language, as the language itself is provided by the compiler, functions like ArrayResize or iCustom, or iMA, are functions provided by the implementation of the terminal64.exe in binary form, by blending in this memory into your "process space", your instance of your ex5 code. This is how these functions come to be available to you in your code.

Now if the standard library is written in the same language, and "wrapping" the actual MQL-API into its own concept, this can be considered a wrapper library. - But that is not true for all content. So its a hybrid, a collection of independent functions, and a wrapper API for the MQL-API.

Okay this is a very nice and thorough expalation, I will keep that in mind as a basic principle. It seems to me mql is some kind of defused C++ and what you said is that executables call each other in like a cascade, that makes sense although I have only a vague idea about the assembler nitty-gritty. Thanks for taking the big tour though

123
New comment