Need help from MT4 developers and programmers - page 7
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
What a load of rubbish...
I also think that looping the EA is a mauvais ton. Changing parameters only after the end of the start cycle is perfectly logical. The topicstarter couldn't help but understand that the problem is in his endless loop, as he's not an amateur. However, he hasn't written anything in the first post about infinite loop in the Expert Advisor. I personally have not implemented such systems in my EAs, but, judging by my posts, I understoodthat this did not happen before- the parameter window in looped EAs simply was not opened. This means that the TC statement"It leads to fundamental incompatibility of existing EAs with the new builds of MT4." is not true - in old builds of MT4, such EAs also did not allow to change parameters, because it was impossible to open the window until the end of the cycle.
EventSetMillisecondTimer does solve the problem. But how long ago this function appeared? Wasn't there just EventSetTimer before? With a minimum call interval of 1 second such an event is completely useless when writing systems for real trading, when there may be dozens of ticks for each symbol per second.
There is still no reference to this function inthe help on timers! I just discovered it by accident, as a hint when entering the EventSet.
There is, however, in my opinion one problem and one inconsistency in the new MQL 4/5: When deinitializing and initializing there is no deletion and re-creation of dynamic objects in global variables...
There is, however, in my opinion, one problem and one inconsistency in new MQL 4/5: Deinitialization and initialization does not remove and re-create dynamic objects in global variables. That is, if parameters of the EA are read in the constructors of dynamically created objects in global variables and the EA continues to work with them, when the parameters are changed, the EA will continue to work as if the parameters have not changed. In my opinion, it is not logical and the global variables should be deinitialized after the EA is deinitialized and then reinitialized before the EA is initialized. This is currently solved by putting the initialization and deleting of such variables in OnInit and OnDeinit
Yes, it's a real rake, especially considering that the documentation (neitherhere norhere) doesn't emphasise that loading is now not linked 1 to 1 with the initialisation event. Here are some words like this:
Global variables are initialised once immediately after the program is loaded into client terminal memory.
is clearly not enough to point out to the developer that subsequent parameter changes will be deinitialized and initialized, BUT NOT the corresponding unloading and loading.
Yes, it's a real rake, especially considering that the documentation (neitherhere norhere) doesn't emphasise that loading is now not linked 1 to 1 with the initialisation event. Here are some words like this:
Global variables are initialised once immediately after the program is loaded into client terminal memory.
is obviously not enough to draw developer's attention to the fact that subsequent parameter changes will deinitialize and initialize, BUT DO NOT perform corresponding unloading and loading.
There is no need to load/unload and re-initialize the variables. The programmer has to take care of the initialisation of the variables.
There is no need to load/unload and re-initialise variables. The programmer has to take care of variable initialization.
That's what I mean: it is not said clearly when this very initialization is done. Code with a global variable:
int x = 0;
this is also initialization. But it is not clearly written in documentation that this is just not initialization from MC's point of view.
Strictly speaking, there are now 2 different initialization in MT: one is performed at program startup and the other is performed when changing the "environment" at the moment of OnInit call. The bad thing is that this has to be unearthed.
A cold start is made when the program is started. Memory is allocated to the variables and initialised with initial values.
When running - warm start. Here the programmer has to take care of initialization of variables and this is good.
A cold start is made when the program is started. Memory is allocated to the variables and initialised with initial values.
When running - warm start. In this case the programmer has to take care of variable initialization and this is good.
Whether it's good or bad is a philosophical question... But the fact that there is 0.0 information about it in the Documentation is not good...
And, if I remember correctly, there was no such thing before, i.e. it is, to put it mildly, a "feature" added specially for "convenience" of programmers, but which violates invariance of existing codes (written for previous initialization rules). Thus, the immutable principle of preserving compatibility of old code with new versions of software wherever possible is not observed.
Nobody is against new features and optimizations. But why not do them in such a way that old code is not broken? In particular, for such new initialization we could allocate additional preprocessor command similar to #property strict. For example, make #property lazyinit, and if it is specified by programmer in code (i.e. explicitly, that means he is aware of new initialization in mql), then we rejoice at optimized optimization. And if it's not specified, then we are glad that previous code works consistently, without any digging and searching for places where global variables could remain, which now not only have to be declared, but also separately initialized in OnInit. For each such variable, there will be 2 lines of code instead of one.