creating external references

  • Thread starter Thread starter Jack Leach
  • Start date Start date
J

Jack Leach

I've been trying to find information on this but have been drawing blanks,
hoping maybe someone can point me in the right direction.

I want to make an external reference library that I can access within my
project, but not sure how to go about doing it. I'm working on a basic CAM
programming interface to integrate, which invloves a ton of various math
forumlas.

I'd like to get these formulas into their own library, which I can
apparently do by referencing a seperate mdb/mde. But I think I'd rather not
have an mdb for this... I don't need any interface or data, just functions,
so an mde is a bit overkill I think.

I assume a dll is ideal for this, but I haven't the faintest idea how to
work with them or what the learning curve is (if I understand correctly vba
cannot create dlls anyway).

Any ideas or pointers to places where I can find good information on the
concept?

Thanks,


--
Jack Leach
www.tristatemachine.com

"I haven't failed, I've found ten thousand ways that don't work."
-Thomas Edison (1847-1931)
 
On Sun, 28 Jun 2009 10:25:01 -0700, Jack Leach <dymondjack at hot mail
dot com> wrote:

Indeed VBA cannot create DLLs of any kind. An MDB/MDE is not overkill
for this, especially if you're not a .NET programmer.

-Tom.
Microsoft Access MVP
 
Hi Jack

The easiest way to implement this is with a referenced MDE. It's very
simple - just create an MDB with nothing in it but modules containing your
code. Then 'compile' it into an MDE and set a reference in your other
projects to the MDE.

Class modules are a bit of a problem, because there is no 'easy' way in
Access to make a class module both Public and Creatable. However, there are
ways around that.

The one major drawback of an MDE is that the class GUID of an MDE changes
every time it is compiled. If your client frontend projects are also MDEs,
the class GUID of the library MDE on the end-user system must exactly match
that of the version that the frontend was compiled with.

This means that, say you add a new function or make an even more minor
change to your library on your development machine, and then recompile
frontend A (which is not affected by the change), then if you redeploy A.MDE
to another machine, you must also redeploy Library.MDE.

Perhaps this might not seem like a problem, but if the destination machine
also has frontends B and C which reference the library, they must be
recompiled and redeployed too, because otherwise they will refuse to work
against the new library.

This can create something of a maintenance nightmare. A workaround is to
deploy the frontends as MDBs (because an MDB will recompile against the new
library next time it is opened), but this is hardly satisfactory.

A much more satisfactory solution is a DLL, but it is much harder to
implement. The advantage is that you can set "Binary compatibility" on a
DLL, which means that all class GUIDs remain the same after a rebuild.
Essentially this removes the inbuilt compatibility protections and leaves in
your hands the responsibility to ensure upward compatibility. You can even
(carefully!) add new, optional arguments to existing methods in your library
without breaking the compatibility.

The disadvantages are:

1. You need VB6 or Visual Studio .NET to create a DLL. Involves expense and
a learning curve.

2. There is no access ('scuse the pun) to the nice, built-in objects such as
Application, DBEngine, CurrentDb, CurrentProject, etc. The workaround to
this is to declare them as properties in your DLL and initialise them at
application startup - for example:
Set MyLibrary.AccessApp = Application

3. If your library uses tables (e.g. error codes for global error handling)
they must be deployed in a separate MDB file. Not really a problem, except
for maintenance.

4. If your library uses forms (e.g. for a general-purpose calendar) then
they must be VB6/.NET forms - usually not a problem, except for the learning
curve.

Hope this is of some help!

--
Good Luck :-)

Graham Mandeno [Access MVP]
Auckland, New Zealand
 
Hi Graham, and thanks for the reply, this was a great help.

It sounds like I'm going to go the MDE route. I try to keep my updates and
maintenence automated so hopefully it shouldn't be too bad to integrate them.

I wonder if it's possible to integrate a reset of the library in my
reference check procedures on startup. If you were to programmatically
reestablish the library based on the updated mde file distributed with an
updater, that would be pretty ideal. I could flag a new version and
re-reference the library. Anyway that's for later.

At least I have some direction and inkling of how this works now.

Thanks much,
--
Jack Leach
www.tristatemachine.com

"I haven't failed, I've found ten thousand ways that don't work."
-Thomas Edison (1847-1931)



Graham Mandeno said:
Hi Jack

The easiest way to implement this is with a referenced MDE. It's very
simple - just create an MDB with nothing in it but modules containing your
code. Then 'compile' it into an MDE and set a reference in your other
projects to the MDE.

Class modules are a bit of a problem, because there is no 'easy' way in
Access to make a class module both Public and Creatable. However, there are
ways around that.

The one major drawback of an MDE is that the class GUID of an MDE changes
every time it is compiled. If your client frontend projects are also MDEs,
the class GUID of the library MDE on the end-user system must exactly match
that of the version that the frontend was compiled with.

This means that, say you add a new function or make an even more minor
change to your library on your development machine, and then recompile
frontend A (which is not affected by the change), then if you redeploy A.MDE
to another machine, you must also redeploy Library.MDE.

Perhaps this might not seem like a problem, but if the destination machine
also has frontends B and C which reference the library, they must be
recompiled and redeployed too, because otherwise they will refuse to work
against the new library.

This can create something of a maintenance nightmare. A workaround is to
deploy the frontends as MDBs (because an MDB will recompile against the new
library next time it is opened), but this is hardly satisfactory.

A much more satisfactory solution is a DLL, but it is much harder to
implement. The advantage is that you can set "Binary compatibility" on a
DLL, which means that all class GUIDs remain the same after a rebuild.
Essentially this removes the inbuilt compatibility protections and leaves in
your hands the responsibility to ensure upward compatibility. You can even
(carefully!) add new, optional arguments to existing methods in your library
without breaking the compatibility.

The disadvantages are:

1. You need VB6 or Visual Studio .NET to create a DLL. Involves expense and
a learning curve.

2. There is no access ('scuse the pun) to the nice, built-in objects such as
Application, DBEngine, CurrentDb, CurrentProject, etc. The workaround to
this is to declare them as properties in your DLL and initialise them at
application startup - for example:
Set MyLibrary.AccessApp = Application

3. If your library uses tables (e.g. error codes for global error handling)
they must be deployed in a separate MDB file. Not really a problem, except
for maintenance.

4. If your library uses forms (e.g. for a general-purpose calendar) then
they must be VB6/.NET forms - usually not a problem, except for the learning
curve.

Hope this is of some help!

--
Good Luck :-)

Graham Mandeno [Access MVP]
Auckland, New Zealand



Jack Leach said:
I've been trying to find information on this but have been drawing blanks,
hoping maybe someone can point me in the right direction.

I want to make an external reference library that I can access within my
project, but not sure how to go about doing it. I'm working on a basic
CAM
programming interface to integrate, which invloves a ton of various math
forumlas.

I'd like to get these formulas into their own library, which I can
apparently do by referencing a seperate mdb/mde. But I think I'd rather
not
have an mdb for this... I don't need any interface or data, just
functions,
so an mde is a bit overkill I think.

I assume a dll is ideal for this, but I haven't the faintest idea how to
work with them or what the learning curve is (if I understand correctly
vba
cannot create dlls anyway).

Any ideas or pointers to places where I can find good information on the
concept?

Thanks,


--
Jack Leach
www.tristatemachine.com

"I haven't failed, I've found ten thousand ways that don't work."
-Thomas Edison (1847-1931)
Click to expand...
Click to expand...
 
Back
Top