Using some functions in a Library with without bindintg it.

xavier.batlle

Member
Local time
Today, 12:53
Joined
Sep 1, 2023
Messages
59
When we want to use an external library in VBA we usualy use Early or Late binding to access their methods or properties, but this example shows we can execute functions in some libraries loading them at runtime without declaring them.

I don't know if it it can be useful or not, but I found it very interesting.

1715439906398.png
 

Attachments

When we want to use an external library in VBA we usualy use Early or Late binding to access their methods or properties, but this example shows we can execute functions in some libraries loading them at runtime without declaring them.
This introduction is slightly misleading. When we talk about Early or Late Binding, we usually mean COM libraries.
Your example is not about COM but about Windows API functions, i.e. standard C exports from a library.

In principle, the basic concept of your approach also works with real COM objects, but is almost never used as the required effort is high and rarely worth it.
I discussed an example of an exception to this rule in my An excursion to the raw COM API with VBA article. - This example is still somewhat Late-bound, as it still depends on the registration of the COM class in the Windows Registry.
I think, it is also possible to load a COM object from an arbitrary file, not (necessarily) registered in the Registry. However, I never even tried this.

I don't know if it it can be useful or not, but I found it very interesting.
I don't think this is something that can be sensibly used in most normal Access applications.
Still, in some situations this is essentially the only possible solution to achieve a desired result. This is exactly how Ivercy supports the MSSCCI-API where it has to load a DLL implementing a set of defined functions without the developer (me) having ever heard about the DLL used at runtime.
 
Note:
I think, it is also possible to load a COM object from an arbitrary file, not (necessarily) registered in the Registry.
A simple solution is to use DirectCOM.dll from Olaf Schmidt.
 
This introduction is slightly misleading. When we talk about Early or Late Binding, we usually mean COM libraries.
Your example is not about COM but about Windows API functions, i.e. standard C exports from a library.

In principle, the basic concept of your approach also works with real COM objects, but is almost never used as the required effort is high and rarely worth it.
Yes, you are right. I found another examples that uses the same approach to call The EXCEL Library, but these examples are useless. What superprised me whas how do they do de call to the libraries using the API : "DispCallFunc"

I discussed an example of an exception to this rule in my An excursion to the raw COM API with VBA article. - This example is still somewhat Late-bound, as it still depends on the registration of the COM class in the Windows Registry.
Thanks, very interesting article

I don't think this is something that can be sensibly used in most normal Access applications.

Still, in some situations this is essentially the only possible solution to achieve a desired result. This is exactly how Ivercy supports the MSSCCI-API where it has to load a DLL implementing a set of defined functions without the developer (me) having ever heard about the DLL used at runtime.
I totally agree!
 

Users who are viewing this thread

Back
Top Bottom