Libraries: Init_Sync

 

Init_Sync:

The library makes indicators' Init/Deinit synchronized

Author: fxsaber

 
And now - a super-duper mega-question: what is the life context of resources created in MQL5? The whole terminal, any internal containers like "symbol-timeframe" streams, chart or something else? It is not written about it in the Help.
 
Stanislav Korotky:
And now - a super-duper mega-question: what is the life context of resources created in MQL5? The whole terminal, any internal containers like "symbol-timeframe" streams, chart or something else? It is not written about it in the help.
I have not checked it

Forum on trading, automated trading systems and testing trading strategies

Sequence of Init() and DeInit() execution

Nikolai Semko, 2017.04.16 09:42 AM

Of course resources - they seem to me the optimal solution, because they are invisible, unlike glob. terminal variables and files, and fast. And also you can transfer arrays through them, as well as through files, but only faster, because everything happens in RAM. And also they belong to the window, not to the terminal, as in the case of global ones. Moreover, you can create one resource for all the same indicators in the window.

I just believed it, that's why I did it through resources. Initially it was through global ones.

 
fxsaber:
Didn't test it

I just believed it, so I did it through resources. Originally it was through global.

It would be interesting to hear some official source of information.
 
And there is one more question - what happens if an indicator is created from an Expert Advisor?
 
Stanislav Korotky:
And there is one more question - what happens if an indicator is created from an Expert Advisor?
Try this.
 

Hmmm...

Interesting function overrides...

How does it work ? Let's say, using the initialisation function as an example ?

So...

So, since the library is inserted first, when compiling OnInit() of the library is registered as an initialisation function.

And it checks synchronisation and then calls the OldOnInit() function. What is this function ? It is not defined yet !


Aha... Further - the OnInit() identifier is defined by the define as OldOnInit(). Later, when the "old" OnInit() function is defined, it will be replaced by OldOnInit() - the same one that will be called by the library's OnInit().


Hmm. The original use of defines. In my opinion, quite dangerous, in terms of further support and possibilities of changing the order of declaration of identifiers. (I was under the impression that you can't use undeclared identifiers). But, from the point of view of usage - everything is clean and correct.

 
George Merts:

In my opinion, quite dangerous, in terms of further support and possibilities to change the order of declaration of identifiers.

I haven't found a dangerous example.


In my memory, this is the only such library where #include is present, but nowhere in the code is anything from it called by the user.

 
fxsaber:
Didn't test it

I just believed it, so I did it through resources. Originally it was global.


I apologise. I was misled.

If you use an empty indicator with such OnInit (without deleting the resource):

int OnInit()
  {
   uint set[1];
   set[0]=3;
   uint w=1,h=1;
   if(ResourceReadImage("::Res_name",set,w,h))
      Print("resource already exists set[0] = "+DoubleToString(set[0],0));
   else
     {
      if(ResourceCreate("::Res_name",set,1,1,0,0,0,COLOR_FORMAT_XRGB_NOALPHA))
         Print("A new resource has been created.");
      else Print("Couldn't create a resource.");
     }

   return(INIT_SUCCEEDED);
  }

you can draw the following conclusions about the resource:

1. The resource belongs to the terminal, not to the window. Therefore, it is reasonable to add, say, a window handle to the resource name.

2. The lifetime of the resource is as long as the terminal is alive, and the resource is deleted when the terminal is restarted. Therefore, it would be reasonable to save the necessary data in the global variable of the terminal (or file via ResourceSave) when the terminal is closed (the reason code is REASON_CLOSE), and when the terminal is loaded again, create a new resource by transferring data from the global PT (or file) with the subsequent deletion of the global PT (or file), so that they do not bother your eyes (then the global variable of the terminal will exist only at the time of closing and opening the terminal).

On the one hand it is good, because there are interesting possibilities of data transfer and synchronisation between windows and in general everything in the terminal, but on the other hand it adds code and some complications.
Sorry again for giving out unverified information.

But now there is clarity with poorly documented resources. And, by the way, a very valuable tool.

 
Nikolai Semko:

The resource belongs to the terminal, not to the window. Therefore, it is reasonable to add, say, a window handle to the resource name.

Then add this to the code
return("::" + (string)::ChartID() + (string)INIT_SYNC::crc64(Bytes) + ::MQLInfoString(MQL_PROGRAM_NAME));

It seems that nothing else is needed.


By the way, it may be convenient without window handle in some situations, when the indicator copy should be ONE for the whole terminal.


ZY The updated version contains this correction.

 
fxsaber:

By the way, perhaps, without window handle can be convenient in some situations, when the indicator copy should be ONE for the whole terminal.


Yeah, I thought about it too

This website uses cookies. Learn more about our Cookies Policy.