Hello everybody, today I faced the problem of interfacing TRNSYS with Types in external libraries. I run into difficulties which seemed caused by a misbehaviour of the dynamic loader in the TRNSYS kernel. Solving the problem I found out that in the file Userlib.f90 one of the three calls to LoadLibrary() system function is not protected against the possible failure of the call (see lines 192-198 of the cited file, reported below).
Do
While (bSt) ! Get a pointer to the DLL that was just found and load all types
p =
LoadLibrary(TRIM(UserDir)//"\\"//WFD%cFileName)
Call
LoadTypesFromDll()
bSt =
FindNextFile(libFile,WFD)
!returns FALSE if another dll is not found LibCount
= LibCount+1
EndDo
The point is that the loading of a library may fail not only because the dll file of that library is not present in the UserLib/Release directory (which is detected by other means) but also, for example, because the library itself links
to another library that for whatever reason is not available. In this case (and that was exactly the case I run into), the messages printed by the kernel are deceiving as they maintain that the library has not been loaded because the type entry point has not
been found in the library. Due to the wrong message, I wasted hours to figure out what was going on, using tools that even an above that average TRNSYS user is probably not aware of. Therefore I suggest to modify the code snippet above by making sure that the pointer
p is not NULL before calling LoadTypesFromDll() and printing a more informative message if this is the case. A simple “Failed to load library <FileName.dll>. Possible dependencies problem” is in my opinion much better than the message that is printed now. Sincerely, _ _ Anton Soppelsa, Ph.D. EURAC research Institute for Renewable Energy t +39 0471 055 623 f +39 0471 055 699 EURAC research Legal Seat Viale Druso 1, I-39100 Bolzano This transmission is intended only for the use of the addressee and may contain confidential or legally privileged information.
P
Think before you print |