[AccessD] Framework book - was caption from code

William Hindman dejpolsys at hotmail.com
Thu Jul 14 01:31:57 CDT 2005


"You would need a copy of Visual Basic or Visual Studio to get the utilities 
required do
that task. Because a large number of Access developers don't have these 
tools, you have not seen any significant number of distributed frameworks 
built entirely in Access." Ken

..for the first time it suddenly dawns on me that packaging the Access 2003 
Developer Tools with VB.Net/Visual Studio might actually have made some kind 
of sense ...I'd just assumed it was another MS ploy to force me to buy stuff 
I had no intention of ever using just to get the old ODE goodies :(

William

----- Original Message ----- 
From: "Ken Ismert" <KIsmert at texassystems.com>
To: "Access Developers discussion and problem solving" 
<accessd at databaseadvisors.com>
Sent: Wednesday, July 13, 2005 6:58 PM
Subject: RE: [AccessD] Framework book - was caption from code


>
> (Jim Dettman)
> <<There was a discussion long ago on this very point; why there were not
> more frameworks available for Access . . . I see that other developers
> have come up with things to solve the very same problems (PK generation,
> pick lists, calendars, etc).  I'm still scratching my head as to why.>>
>
> A fundamental barrier is the lack of an easy way to distribute true
> components for use in Access. Any framework library built entirely in
> Access lacks a reliable way to share objects with its clients. For
> Office 2000 and later, the Office Add-In was touted by Microsoft as a
> way of building components for the Office Suite. But it suffers from the
> same object-sharing drawbacks as libraries, and because of its extremely
> limited distribution, has generated very little interest from the Access
> developer community.
>
> The core technical limitation centers around Access and its use of COM.
> Access uses Project Compatibility for generating the GUIDs required for
> identifying objects and their interfaces. Project Compatibility means
> the object IDs are private to the project, and are re-generated each
> time you fully-compile the project. That produces behavior noted before
> in this group: when you reference the library in an MDB, and compile
> them together, you can share objects, because Project Compatibility
> enforces consistency between the two. But, if you open the library
> separately, and save changes, the MDB referencing it will break, because
> all the old object IDs have been replaced in the new library.
>
> The way out of this dilemma is to build a Type Library, or TLB file. The
> TLB is a separate file which provides a stand-alone, unchanging
> definition of the objects and interfaces to be shared between the MDB
> and the library. Both the MDB and library reference the TLB, and use it
> when declaring shared objects. This way, the library can be updated
> independently of the MDB, shared between multiple MDBs, and distributed
> to third parties. The TLB is the key ingredient that enables reliable
> object sharing.
>
> The catch is, you can't make a Type Library in Access. You would need a
> copy of Visual Basic or Visual Studio to get the utilities required do
> that task. Because a large number of Access developers don't have these
> tools, you have not seen any significant number of distributed
> frameworks built entirely in Access.
>
> -Ken
> -- 
> AccessD mailing list
> AccessD at databaseadvisors.com
> http://databaseadvisors.com/mailman/listinfo/accessd
> Website: http://www.databaseadvisors.com
> 



More information about the AccessD mailing list