Find File problems. - page 2

New comment
 

If the error with global variables has gone why not to use this method? Actually, if there is a bug in the tester or terminal (related to the global variables or whatever else) we will find it and they will fix it.

The idea with a stub is as follows. For example, if you have a library.dll with exported function runTask, create a libraryWrapper.mq4 file (in Libraries subfolder) and code runTaskWrapper function with the same signature (parameter list and return type) and export modificator. Your EA should import the libraryWrapper.ex4 from now on, and call functions from it. The libraryWrapper in turn has 2 versions. First imports actual dll and calls corresponding functions (such as runTask) from wrappers (such as runTaskWrapper). Second imports nothing and does nothing (runTaskWrapper is empty), but there will be no errors.

You can distribute EA with the empty wrapper by default, and then send redirecting version with DLL file when necessary.

 
Silly question, but instead of Global Vars, what about a named pipe? They are global to the machine, implement lazy loading, and are registered inside MQL5. The Named Pipes are also global to the machine by default. The library wrapper idea might be what you're looking for, but named pipes are superior to global variables in terms of security and scope imho.
12
New comment