Call VB procedures from Access

  • Thread starter Thread starter GeorgeMar
  • Start date Start date
G

GeorgeMar

When I want to run a procedure that exists in another
Access database, I use the .run method to do so. e.g.

dim app as New Access.Application
app.OpenCurrentDatabase "databasename",False,"password"
app.run "procedure","arg1","arg2"
app.CloseCurrentDatabase

If I want to call a procedure that exists in a VB EXE or
DLL, what method would I use?

many thanks
george
 
Set a reference to the ActiveX EXE or DLL (Tools | References when you have
a code module open).

Assuming you know how to refer to the object, you then do essentially what
you did for Access below:

Dim obj As XXX.YYY

Set obj = New XXX.YYY
obj.Method1
txtResult = obj.ReturnValue
Set obj = Nothing

etc.
 
Thank you Doug

I am not sure what XXX.YYY would be, if say the DLL is
called VB1.DLL

Also, because the application can be installed in
diferrent paths and I want to use a function or sub from
that DLL, the reference will have to be reset each time,
would it not?.

I have been looking at help and I was wondering if Declare
could possibility be used?

many thanks
george
 
It depends what kind of DLL you're talking about. ActiveX DLLs aren't
Declared: they're added as References. Non-ActiveX DLLs can't be added as
References, they must be Declared. VB can only create ActiveX DLLs.

I used XXX.YYY to represent the class information from your DLL. It's the
equivalent of Access.Application that you used in your example. I believe
XXX will be the name of your ActiveX project in VB, and YYY will be the name
of the specific object in it you wish to instantiate. It may be that XXX
will be VB1, but because the project was named that, not because it was
compiled to VB1.DLL (they don't have to be the same thing)

Yes, moving VB1.DLL to a different location can cause the Access References
to get broken.

A further complication I forgot to mention is that Access isn't capable of
working with just any old ActiveX DLL: there are specific things that must
be present, and other that cannot be present in the DLL for Access to be
able to use it. Check http://support.microsoft.com/?kbid=202104 for details
(don't worry about the fact that the article only mentions Access 2000: it's
the same for all versions)
 
Thank you again.

I have an MDB(Called Utils) that contains a number of Subs
and Functions that are called from other MDB's. I was
going to convert that Utils MDB to an Activex DLL because
the MDB is growing too big in size and I would hope that a
DLL would also be faster.

The questions are 1. Would converting to a DLL help
significantly? 2. Since Declare won't recognise the
Activex DLL, am I back to square one with Reference and
the problem of the DLL's location?

Thanks
george
 
I doubt very much that you'll see much of a performance improvement by
converting to a DLL.

Why can't you control where the DLL gets installed, though?
 
Thank you Doug, I shall heed your advice.

George
-----Original Message-----
I doubt very much that you'll see much of a performance improvement by
converting to a DLL.

Why can't you control where the DLL gets installed, though?


--
Doug Steele, Microsoft Access MVP

(no e-mails, please!)






.
Click to expand...
 
Back
Top