Open EA Input-Settings, press OK, and the OnInit() executes TWICE

 

Open EA Input-Settings and press OK, with or without changes, and the OnInit() executes TWICE. Really messes with the idea of trying to politely handle errors. Anyone else noticed this and reported it?

At first I thought it might be my complex coding, so I grabbed sample code from the Code Base. Can recreate problem with minimal code -- example attached.

[ ... and I totally support the concept that us anonymous beta-testers should be paid for all our hard work <g> ]


Experts Log...

16:59:54 Expert example AUDNZD,M1: loaded successfully
16:59:57 example AUDNZD,M1 inputs: Lots=0.1; YourTrendPrediction=0; YourTrendTimeframe=0; TheTrendBeginsOn=1393432830; TheTrendFinishesOn=1393432830; EAsAggressiveness=0;
16:59:57 example AUDNZD,M1: initialized
17:00:16 example AUDNZD,M1: uninit reason 5
17:00:16 example AUDNZD,M1: initialized
17:00:16 example AUDNZD,M1 inputs: Lots=0.1; YourTrendPrediction=0; YourTrendTimeframe=0; TheTrendBeginsOn=1393432830; TheTrendFinishesOn=1393432830; EAsAggressiveness=0;
17:00:16 example AUDNZD,M1: uninit reason 5
17:00:16 example AUDNZD,M1: initialized
Files:
example_1.mq4  6 kb
 
ballenoz:

Open EA Input-Settings and press OK, with or without changes, and the OnInit() executes TWICE. Really messes with the idea of trying to politely handle errors. Anyone else noticed this and reported it?

At first I thought it might be my complex coding, so I grabbed sample code from the Code Base. Can recreate problem with minimal code -- example attached.

[ ... and I totally support the concept that us anonymous beta-testers should be paid for all our hard work <g> ]

...
Why are you reporting this twice, do you also have a bug ?
 
angevoyageur:
Why are you reporting this twice, do you also have a bug ?


Since there was no response in the other place, I have no indication who reads what. Just trying to report a potential problem!! Can't blame me for trying.

Perhaps it would be more helpful if you could confirm the problem and escalate it as required.

 
ballenoz:

Since there was no response in the other place, I have no indication who reads what. Just trying to report a potential problem!! Can't blame me for trying.

Perhaps it would be more helpful if you could confirm the problem and escalate it as required.

I was joking, don't worry this will be reported.
 
angevoyageur:
I was joking, don't worry this will be reported.

Thanks.

If confirmed, I imagine this is a pretty serious bug since it has the potential to make some code execute in unanticipated ways. Many coders, such as myself, will dance around trying to figure out what we did wrong. Or even worse, the problem may go unnoticed until it has been distributed to clients.

And I'm not sure that I can find a simple work-around. Any suggestions?

 
Are you sure its loading twice? Those timestamps are a bit off
 
tinashe:
Are you sure its loading twice? Those timestamps are a bit off
The relevant ones are with timestamp of 17:00:16.
 
ballenoz:

And I'm not sure that I can find a simple work-around. Any suggestions?

The OnDeinit() is executed between those two inits, so the repeated execution should cause no harm. When this bug appeared for the first time, it did not execute the OnDeinit between inits, which was worse case. So I do not think any workaround is necessary.
 
Ovo:
The OnDeinit() is executed between those two inits, so the repeated execution should cause no harm. When this bug appeared for the first time, it did not execute the OnDeinit between inits, which was worse case. So I do not think any workaround is necessary.

For those who write simple 20-line programs, probably no harm done. For industrial-strength programs that handle input errors in a timely fashion, or have complex DLL initiation code, a work-around IS required. Rather than rewrite code that used to function perfectly [ when the OS followed the specifications ], I used the following as a TEMPORARY fix and all works as it should. Please note that if you use this code, I take no responsibility if it does not work.

//==== Entry-point from main program ====================================
int OnInit() {

if ( !fnGlobalCheck("deinit_code") || fnGlobalGet("deinit_code") != REASON_PARAMETERS )
return(MyOnInit());

if ( !fnGlobalCheck("init_time") || fnGlobalGet("init_time") == 0 ) {
fnGlobalSet("init_time", TimeCurrent());
return(INIT_SUCCEEDED);
}

datetime last_init_time = (datetime)fnGlobalGet("init_time");
fnGlobalSet("init_time", TimeCurrent());

if ( TimeCurrent() - last_init_time >= 2 )
return(INIT_SUCCEEDED);

return(MyOnInit());
}

//==== Dummy entry-point from main program ====================================

int MyOnInit() {

...


//==== Entry point from main program() ====================================
void OnDeinit( const int ReasonCode ) {
ret_code = GetLastError();
fnGlobalSet("deinit_code", ReasonCode);
...

 
ballenoz:

For those who write simple 20-line programs, probably no harm done. For industrial-strength programs that handle input errors in a timely fashion, or have complex DLL initiation code, a work-around IS required. Rather than rewrite code that used to function perfectly [ when the OS followed the specifications ], I used the following as a TEMPORARY fix and all works as it should. Please note that if you use this code, I take no responsibility if it does not work.

This is probably why the industrial codes have so many lines, while ours have only 20. I would code it like that:

void OnInit() {
      static int check = 0;
      if(check==0) MyInit();
      check = 5;
}
 
The secret to industrial-strength code is that it actually works <g>.
Reason: