OMEdit fails to find local dlls on Windows

[Per Östlund]

If a model uses an external function which specifies a library by using the Library annotation, and the library is in a DLL in the same folder as the model, then OMEdit will fail to execute
the simulation executable. The error message isn't very user friendly, just stating that the simulation crashed and returned the error code -1073741515, which is 0xC0000135 == STATUS_DLL_NOT_FOUND. The reason is simply that OMEdit runs the simulation in %TEMP%/OpenModelica/OMEdit/ and not the folder the model is in, so it will fail to find the dll.

On Linux this works automagically, and it would be nice if it would work on Windows too (and maybe MacOS, I haven't tried it). And maybe it's possible to display error codes in a human readable format too?

[Per Östlund]

Attached is a test model which uses an external object to read from an excel sheet, which uses ​libxl. No excel sheet is included, the model should just print an error message that it couldn't open the sheet if it works, or crash if it doesn't.

[Adeel Asghar]

Ofcourse this can't work automatically. For translating the model I have to specify the libxl include files directory via cflags option.

If user downloads and installs the libxl in Windows PATH then the system will automatically find the needed header files for compilation and dll for execution.

I don't know how you install libxl in Linux. Perhaps it is in PATH. Because even in Linux OMEdit working directory is %TEMP%/OpenModelica/OMEdit/ so how can OMEdit find the binary?

Also the user can set the working directory via Options before running the simulation.

[Adeel Asghar]

Fixed in r25450.

[Dietmar Winkler]

It doesn't make sense to keep closed ticket in the "Future" milestone that were simply forgotten to assign to the correct milestone in the past.

[Martin Sjölund]

Removing the pre1.9.4 milestone in favor of 1.9.4.