Getting MS Access/VBA to work with an external/referenced DLL correctly
I have a .Net developer creating a DLL that we are going to Reference in an Access VBA application. However, whilst we can see the DLL methods (once referenced), he is struggling with a couple of aspects such as passing variables through and how best the code the .DLL so that Intellisense works as expected.
Whenever I have worked with external references in the past, I usually access them like this (rough example):
However, he has never worked in VBA and is struggling with the various aspects. His list of questions is below, but I was wondering if anyone had any links/suggestions for him to look at (more than just answering his questions).
Which kind of methods works?
Do properties work?
Constructors work, what about parameters?
How to do event pattern for a custom class and not UI control?
What pieces (that we use regularly) in C# that does not work with VBA when referenced?
Any article/doc that can be referred that has details for questions like above?
Any help would be greatly appreciated - sorry it's so vague.
Whenever I have worked with external references in the past, I usually access them like this (rough example):
Dim obj1 As New TSDialler.Dialer
obj1.SignalKey = "ABC123456"
obj1.TelephoneDestination = "0123456789"
obj1.InternalID = "ZYX987"
If obj1.MakeCall = 1 Then
MsgBox "Call made"
Else
MsgBox "Call not made. Error: " & obj1.ReturnMessage
End IfHowever, he has never worked in VBA and is struggling with the various aspects. His list of questions is below, but I was wondering if anyone had any links/suggestions for him to look at (more than just answering his questions).
Which kind of methods works?
Do properties work?
Constructors work, what about parameters?
How to do event pattern for a custom class and not UI control?
What pieces (that we use regularly) in C# that does not work with VBA when referenced?
Any article/doc that can be referred that has details for questions like above?
Any help would be greatly appreciated - sorry it's so vague.
You might find this helpful:
https://www.c-sharpcorner.com/article/writing-an-activex-control-in-net/
and:
http://www.geeksengine.com/article/create-dll.html
Jim.
https://www.c-sharpcorner.com/article/writing-an-activex-control-in-net/
and:
http://www.geeksengine.com/article/create-dll.html
Jim.
ASKER
Jim - if you were developing this, would you have a preference?
My preference is a straight DLL call, but then I'm a bit "old school". However without having any idea of what your developing or how it will be used, it's hard to say one way or the other.
But a straight DLL is always simpler to develop (no COM interface).
Jim.
But a straight DLL is always simpler to develop (no COM interface).
Jim.
ASKER
Thanks Jim - I'll pass the advice on and see what comes back.
I should add that in using .Net (and I assume C#), a COM object is probably simpler. The articles I posted show you how.
A direct DLL setup is something you'd typically do with using something like C++ rather than .Net.
Jim.
A direct DLL setup is something you'd typically do with using something like C++ rather than .Net.
Jim.
ASKER
Thanks again Jim.
This question needs an answer!
Become an EE member today
7 DAY FREE TRIALMembers can start a 7-Day Free trial then enjoy unlimited access to the platform.
View membership options
or
Learn why we charge membership fees
We get it - no one likes a content blocker. Take one extra minute and find out why we block content.
Keep in mind that there are two different ways of interacting with a DLL:
1. DLL calls
2. As a COM object.
Straight DLL calls are done with DECLARE statements (think Win API). You write the Declare, then in VBA code just call the routine.
The example you gave in the question is declaring an object, which is a totally different thing, and the type lib developed would need to present a COM interface.
Jim.