[AccessD] Framework Discussion - Who's following this

John,

>Yea... in a perfect world.  Unfortunately for most of us a framework is not
>a project which we spec out and write, but rather a living entity that we
>add functionality to on a weekly basis.  Thus feature bloat is an inherent
>part of doing business, and there is never a finish, much less a timely
one!

Evolution is a valid development method, especially when the path ahead is
not clear. I often find, though, that doing an informal design using pencil
and paper saves time. It helps separate needs from wants. Do I really need
3-D animated text on my Message Box replacement? It may be vital, but if it
isn't, leave it out for now.

Of course, a framework implies an organization of function. So, how do we
organize a constantly changing function set? By providing standard methods
of extending the framework. Careful design here can have an enormous payoff.
This is where interfaces can play a role.

> ... I think it is important to NEVER accept the limitations of your
>platform.  Much of what my framework does is nothing more than an attempt
by
>me to program around the limitations of Access ...

Removing arbitrary limits is a worthy pursuit. Don't like the
[Forms]![Form]![Control] method of synchronization? Replace it with your own
global parameter collection. Want to enforce standard behavior for ComboBox
NotInList events? Write an event-sinking class that provides that
functionality. All good. The tools of object programming and abstraction
give us ample power to work around such limitations.

It gets a little trickier when dealing with the platform's warts, like not
automatically terminating an out-of-process object. Here, limits can't be
satisfactorily removed, and the best we can offer is workarounds and advice.

There are certain things the platform will never do gracefully. I tend to
draw the line at fixes/extensions that involve:
 * Risky VB programming practices (handling Object pointers as longs, LSet
abuse, etc.)
 * Extensive use of the Windows API. Just way out of my field of expertise.
Should be delivered as a .DLL, anyway.
 * Reliance on version-specific quirks or bugs
 * Undocumented features (although some, like Decompile, are essential)

-Ken

Biedermeier - a German furniture style of the early-to-mid 19th century. A
break from the highly decorative styles which preceded it, Biedermeier
emphasized durable construction, the intrinsic beauty of the wood,
restrained decoration, and simplicity of design. Some of the pieces
belonging to this style have a very modern look to them.