Sign in to follow this  
Followers 0
martin

DllCall using a handle - does it matter?

3 posts in this topic

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??


Serial port communications UDF Includes functions for binary transmission and reception.printing UDF Useful for graphs, forms, labels, reports etc.Add User Call Tips to SciTE for functions in UDFs not included with AutoIt and for your own scripts.Functions with parameters in OnEvent mode and for Hot Keys One function replaces GuiSetOnEvent, GuiCtrlSetOnEvent and HotKeySet.UDF IsConnected2 for notification of status of connected state of many urls or IPs, without slowing the script.

Share this post


Link to post
Share on other sites



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.

Share this post


Link to post
Share on other sites

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.


Serial port communications UDF Includes functions for binary transmission and reception.printing UDF Useful for graphs, forms, labels, reports etc.Add User Call Tips to SciTE for functions in UDFs not included with AutoIt and for your own scripts.Functions with parameters in OnEvent mode and for Hot Keys One function replaces GuiSetOnEvent, GuiCtrlSetOnEvent and HotKeySet.UDF IsConnected2 for notification of status of connected state of many urls or IPs, without slowing the script.

Share this post


Link to post
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!


Register a new account

Sign in

Already have an account? Sign in here.


Sign In Now
Sign in to follow this  
Followers 0