DllCall using a handle - does it matter?

[martin]

The help file says

If a dll filename is given then the DLL is automatically loaded and then closed at the end of the call. If you want to manually control the loading and unloading of the DLL then you should use DllOpen and DllClose and use a handle instead of a filename in this function.

I have been opening dll's with DllOpen then using DllCall with the Dll name not the handle. The examples I see in this forum do the same. If a handle must be used instead of the dll name then I would think a lot of UDFs would need to be rewritten.

I have tried changing to use handles in a case where I am having problems but using a handle seems to make no difference even whether there is a problem or not.

Am I reading this incorrectly??

[Valik]

The handle will be slightly faster in theory since it avoids a reference count. I'm not sure if the speed is measurable, however. That would be the only difference in using a handle versus the filename in cases where DllOpen() was previously called. Of course, if DllOpen() wasn't called, then using the filename loads the DLL, calls the function and unloads the DLL. This can be expensive performance-wise if multiple calls are made to the same DLL. And then there's state data the DLL may keep which may be required across multiple calls to one or more functions in the DLL. Not opening the DLL will lose this state data.

The biggest reason I can give you for going ahead and using the handle instead of the filename is it makes the code self-documenting. You or somebody else may come along later and see the DllOpen() but never see the handle used until DllClose(). That may lead to the assumption that it's not necessary to open the DLL and so that code will be removed. Then the program may develop unexpected bugs or have a performance impact because of the loading and unloading on-demand. By using the handle, it becomes clear that keeping the DLL loaded is important and shouldn't be messed with.

[martin]

The handle will be slightly faster in theory since it avoids a reference count. I'm not sure if the speed is measurable, however. That would be the only difference in using a handle versus the filename in cases where DllOpen() was previously called. Of course, if DllOpen() wasn't called, then using the filename loads the DLL, calls the function and unloads the DLL. This can be expensive performance-wise if multiple calls are made to the same DLL. And then there's state data the DLL may keep which may be required across multiple calls to one or more functions in the DLL. Not opening the DLL will lose this state data.

The biggest reason I can give you for going ahead and using the handle instead of the filename is it makes the code self-documenting. You or somebody else may come along later and see the DllOpen() but never see the handle used until DllClose(). That may lead to the assumption that it's not necessary to open the DLL and so that code will be removed. Then the program may develop unexpected bugs or have a performance impact because of the loading and unloading on-demand. By using the handle, it becomes clear that keeping the DLL loaded is important and shouldn't be messed with.

Thanks for the reply Valik, that helps me. I am glad no state data is lost by using the dll name, but I will try to use handles from now on.