[AccessD] FMS Inc. Sourcebook

Lambert,

I guess I don't understand where the argument is?

>A "library" is a grouping of executable code which can be linked to or have
references set to and the code within becomes available to the client
application.

Exactly, is that not what I said?  The only thing I add to that is that in
order to truly function as an (effective) library the code maintenance needs
to occur in a single location - fix once, fix everywhere.  You can call an
MDB application a library if you want (by your definition), since it can be
referenced by something else to use code within it, but if there is not a
single point of repair then it is just a code container.  

I have to guess that you are picking semantic nits here?  I am discussing
(or trying to anyway) a concept which is specifically "fix once, fix
everywhere".  The fact that you can violate that using some loophole or
another is beside MY point.  My point is very simply that "cut and paste"
from a code repository is asking for nightmarish maintenance issues.  A
"library" or whatever you wish to call it, is an effective method of solving
that nightmarish maintenance issue.

>Typically, whenever a library file is modified in any way all the client
applications need to be recompiled as the references/jump tables (or
whatever else is used behind the scenes to define the code entry points)
will have changed.

True in a compiled environment.  In an Access environment this is only true
if the library is an MDE (and / or possibly the app is an MDE).  If it is an
MDA lib and an mdb FE then this is not true.

>I can put a bunch of code modules into an Excel file, and in the VBA IDE I
can set the project name to something other than "VBAProject". After I save
the Excel file I am then able to set a reference to it in another Excel and
the (public) routines in the referenced file will be available for use. I
have a library.

You can reference an XLS?  I was not aware of that.  If you use the
reference wizard (in Access), the drop down has a very specific list of file
types and no excel file types are included in that list.

If what you say is true then XLSs can function as a code container or
library.  Can you do the same thing with a .DOC file?

John W. Colby
Colby Consulting
www.ColbyConsulting.com

-----Original Message-----
From: accessd-bounces at databaseadvisors.com
[mailto:accessd-bounces at databaseadvisors.com] On Behalf Of Heenan, Lambert
Sent: Thursday, May 03, 2007 2:47 PM
To: 'Access Developers discussion and problem solving'
Subject: Re: [AccessD] FMS Inc. Sourcebook

I'm on Charlotte's side with this one. :-)

A "library" is a grouping of executable code which can be linked to or have
references set to and the code within becomes available to the client
application. No cutting and pasting involved. The point being that the code
in question is immediately usable by the client once the linkage has been
established. There's also no cherry picking of code routines to make
available. Link to a library and you get it all.

Typically, whenever a library file is modified in any way all the client
applications need to be recompiled as the references/jump tables (or
whatever else is used behind the scenes to define the code entry points)
will have changed.

"<snip>
Access is the ONLY Office application that allows libraries but they are
indeed libraries. 
<snip>"

I can't agree with that statement either. I can put a bunch of code modules
into an Excel file, and in the VBA IDE I can set the project name to
something other than "VBAProject". After I save the Excel file I am then
able to set a reference to it in another Excel and the (public) routines in
the referenced file will be available for use. I have a library.

Lambert
--
AccessD mailing list
AccessD at databaseadvisors.com
http://databaseadvisors.com/mailman/listinfo/accessd
Website: http://www.databaseadvisors.com