custom libraries /references

  • Thread starter Thread starter Guest
  • Start date Start date
G

Guest

We use custom libraries for our developed application under Access 2002/2003.
The total application, as well as all the libraries are compiled (.mde).

If changes or simply adding a new module in one of the libraires are made,
the recompiled librairy is not recognized anymore by all the databanks using
this particular librairy, even though the modification or additonal new vba
module is not applicable for the databank we use. In other words, we have to
make a complete new .mde set of all the databanks using this particular
librairy.
I think this is not normal - is there anybodywho knows more about
it?procedure.

Thanks for input
 
Friedi said:
We use custom libraries for our developed application under Access
2002/2003. The total application, as well as all the libraries are
compiled (.mde).

If changes or simply adding a new module in one of the libraires are
made, the recompiled librairy is not recognized anymore by all the
databanks using this particular librairy, even though the
modification or additonal new vba module is not applicable for the
databank we use. In other words, we have to make a complete new .mde
set of all the databanks using this particular librairy.
I think this is not normal - is there anybodywho knows more about
it?procedure.

Thanks for input
Click to expand...

It is normal and AFAIK there is no way around it.
 
It is normal. If you're a VB developer, referencing an MDE is similar to
referencing a DLL where compatibility was broken or the project was not set
to binary compatible. You must have personal control over the source for
any MDEs your application references and understand that if any one of the
referenced MDEs is changed in any way, you need to recompile your
application.

For the reason above, using a referenced MDEs has very little benefit from a
code reuse standpoint unless the referenced MDE is stable and never changed.
If the goal is code reusability, you should consider building an ActiveX
DLL.

An alternative to using a referenced MDE, which may be useful to you, is to
create an Access add-in. You can then load the add-in, and run code in it
using Application.Run. Assuming you've built and installed the add-in
properly, you'd do something like this:

Dim cbrctl1 As Variant
Dim cbrctl2 As Variant
Dim cbr As Variant

Set cbr = CommandBars("Menu Bar")
Set cbrctl1 = cbr.Controls("&Tools").Controls("Add-&Ins")

Set cbrctl2 = cbrctl1.Controls(strTheMenuNameForTheAddin)
cbrctl2.Execute 'This executes the default procedure for starting the
add-in

Application.Run "[strYourAddinProjectName].SomeFunction"

Using this method has some drawbacks.

1. It is slower.
2. It is more difficult to maintain, because you basically have to write
wrapper functions within your main app for each function used in the add-in
3. You app might break if the function in the add-in is somehow changed or
removed


I personally use both referenced MDEs and an ActiveX DLL. However, in the
case where I use a referenced MDE, the main application file and all the
referenced MDEs are compiled/distributed as a set. I am primarily using
these referenced MDEs as a method to segregate functionality within a very
large app (thousands of queries, 40,000 lines of code, hundreds of forms,
and reports). This helps a from maintenance perspective. Code reuse is not
the main concern...my reusable code is placed in the DLL.

I also use the add-in method described above in this same app as a means to
provide limited custom functionality. For example, I have code that
executes during startup to check whether an add-in should be loaded...it
loads, shows its toolbar, and then the custom functions are initiated from
that toolbar.

Hope this helps.
 
Paul,
thank you for your professional and clear answer
and proposing using Dll's or Add-ins . Neither suits us -
we will continue using referenced MDE 's.
But your answer clarified the situation

Thanks
--
Friedi


Paul Overway said:
It is normal. If you're a VB developer, referencing an MDE is similar to
referencing a DLL where compatibility was broken or the project was not set
to binary compatible. You must have personal control over the source for
any MDEs your application references and understand that if any one of the
referenced MDEs is changed in any way, you need to recompile your
application.

For the reason above, using a referenced MDEs has very little benefit from a
code reuse standpoint unless the referenced MDE is stable and never changed.
If the goal is code reusability, you should consider building an ActiveX
DLL.

An alternative to using a referenced MDE, which may be useful to you, is to
create an Access add-in. You can then load the add-in, and run code in it
using Application.Run. Assuming you've built and installed the add-in
properly, you'd do something like this:

Dim cbrctl1 As Variant
Dim cbrctl2 As Variant
Dim cbr As Variant

Set cbr = CommandBars("Menu Bar")
Set cbrctl1 = cbr.Controls("&Tools").Controls("Add-&Ins")

Set cbrctl2 = cbrctl1.Controls(strTheMenuNameForTheAddin)
cbrctl2.Execute 'This executes the default procedure for starting the
add-in

Application.Run "[strYourAddinProjectName].SomeFunction"

Using this method has some drawbacks.

1. It is slower.
2. It is more difficult to maintain, because you basically have to write
wrapper functions within your main app for each function used in the add-in
3. You app might break if the function in the add-in is somehow changed or
removed


I personally use both referenced MDEs and an ActiveX DLL. However, in the
case where I use a referenced MDE, the main application file and all the
referenced MDEs are compiled/distributed as a set. I am primarily using
these referenced MDEs as a method to segregate functionality within a very
large app (thousands of queries, 40,000 lines of code, hundreds of forms,
and reports). This helps a from maintenance perspective. Code reuse is not
the main concern...my reusable code is placed in the DLL.

I also use the add-in method described above in this same app as a means to
provide limited custom functionality. For example, I have code that
executes during startup to check whether an add-in should be loaded...it
loads, shows its toolbar, and then the custom functions are initiated from
that toolbar.

Hope this helps.

--
Paul Overway
Logico Solutions, LLC
www.logico-solutions.com


Friedi said:
We use custom libraries for our developed application under Access
2002/2003.
The total application, as well as all the libraries are compiled (.mde).

If changes or simply adding a new module in one of the libraires are made,
the recompiled librairy is not recognized anymore by all the databanks
using
this particular librairy, even though the modification or additonal new
vba
module is not applicable for the databank we use. In other words, we have
to
make a complete new .mde set of all the databanks using this particular
librairy.
I think this is not normal - is there anybodywho knows more about
it?procedure.

Thanks for input
Click to expand...
Click to expand...
 
Back
Top