Mt4 End of support. - page 19
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
A piece of advice from a self-taught person:
To make the transition to mql5 easier, it is desirable to use not int period variables in mql4 but from the enum ENUM_TIMEFRAMES
Why?
Because when implementing such a thing through other languages, I have a hard time figuring out how to get into the terminal. It can open anything and everything, and if it's implemented through µl, then you can also put bots in it via buttons.
And you can also put a database, then some more software, and carry all your stuff around in one iconI am happy to believe that your problems cannot be solved without them. You have to get into the details to not believe it :)
Spin
Now on one tick we have to determine the new bar on H1, M5 and D1. That is, the first 1 hour 5 minutes the Expert Advisor sleeps and only at 1:05 of a new day it has to wake up and do something.
That will be 3 global variables? And what if we need to do the same thing in 2-3-7 Expert Advisors? How many more varieties of names of global variables should we create?
I will solve the task in my own way. The main thing - the function must work well and not slow down the program and be used on both terminals. The rest is up to me.
Your procrastination in providing a solution is an eloquent answer. Because with OOP the problem is solved simply and standardly without any thinking.
I will solve the problem in my own way. The main thing is that the function should work well and not slow down the program and be used on both terminals. Leave the rest to my discretion.
Your procrastination in providing a solution is an eloquent answer. Because with OOP the problem is solved simply and standardly without any thinking.
I am happy to believe that your problems cannot be solved without them. You have to go into the details to believe it :)
I have heard many people complain that "working with indicators on MT5 is much more complicated than on MT4.
Well, the OOP approach allows to unify this work so that the Expert Advisor is not interested in which platform it is running on.
I have it organized this way.
If we need an indicator (say, the MA) - the Expert Advisor has to declare the object CMA_IParams:public CIndicatorParamsI, in which it stores all of the MA parameters we need. Then pass a pointer to this structure to the Data Provider, in the GetIndicator() function. This function will return the pointer to the CIndicator virtual interface. That's it. This interface has all the necessary data about the called indicator.
If you need any other indicator, the derived object of the CIndicatorParamsI interface is declared, all parameters of the indicator are written into it and it is passed to the data provider, instead the pointer tothe created indicator is returned.
When a new indicator is required - its portable code is written to the data provider, then again - any user can request a new indicator from the data provider, passing its parameters to the data provider.
As a result - say, if an Expert Advisor works "to return to the mean" - it becomes very easy to change this very mean, for example, take the Price Channel middle instead of the MA - just by changing the parameter object.
I wonder how this is organised for fans of the procedural approach?
People often complain that "working with indicators on MT5 is much more complicated than on MT4.
So, the OOP approach allows to unify this work, so that the Expert Advisor, again, is not even interested in what platform it is running on.
I have it organized this way.
If we need an indicator (say, the MA) - the Expert Advisor has to declare the object CMA_IParams:public CIndicatorParamsI, in which it stores all the parameters of the MA that we need. Then the pointer to this structure should be passed to the Data Provider in the GetIndicator() function. This function will return the pointer to the CIndicator virtual interface. This interface contains all the necessary data about the called indicator.
If you need any other indicator, the derived object of the CIndicatorParamsI interface is declared, all parameters of the indicator are written into it and it is passed to the data provider, the pointer tothe created indicator is returned instead.
When a new indicator is required - its portable code is written to the data provider, then again - any user can request a new indicator from the data provider, passing its parameters to the data provider.
As a result - say, if an Expert Advisor works "to return to the mean" - it becomes very easy to change this very mean, for example, take the middle of Price Channel instead of MA - just by changing the parameter object.
I wonder how this is organised for fans of the procedural approach?
I'm sorry, I have to leave. Orders came in... If you don't mind, we'll continue tomorrow.
I'm sorry, I have to leave. Orders came in... If you don't mind, we'll continue tomorrow.
There's an order for him to go west?