[AccessD] .NET Form Object Frameworks -- WAS: Data interface Thebest way

<<<
* Access Form objects have no parameterized constructor (a true
Initialize event with a user-definable parameter list). Form_Open
happens way too late for my purposes. (Maybe Access 2005 will correct
this)
You can trick around this limitation using:

- fake recordsources;
- fake subforms, which are created before mainform.

<<<
* No easy way to deliver the framework. COM-based approaches would
require Active-X dlls, developed in VB6.
>>>
In fact it's relatively easy to convert VBA code into VB6 ActiveX Dlls if
there is no CurrentDB, CodeDB,  DbEngine(..), DoCmd... and similar code
constructs chaotically distributed in VBA code...

<<<
.NET seems to provide some answers:
>>>
Yes, .NET is much better to build such frameworks.
And taking into account a very sad story of Bruce
McKinney(http://brucem.mystarband.net/) - the author of excellent book
"HardCore Visual Basic":

http://vb.mvps.org/hardcore/html/notessecondinternetedition.htm

I'd not recommend now to spend any time on hardcore experiments with VBA -
it is not worth the trouble...

<<<
Of course, the larger question is, "why do this?".
>>>
"Just for fun"? (But ptogramming on .NET is much more fun... C# and C++ is
even more fun... Ruby (people say) - is enormous fun - maybe better start
learning Ruby, especially taking into account mentioned here Ruby on Rails
framework and other Ruby related stuff?)

<<<
Maybe Microsoft will
revive enough developer interest in its next release of Access to
justify investing in such a framework.
>>>
It looks like MS Access is becoming pure power users tool.
MS SQL Server 2005 Express Edition is becoming its killer as developer's
platform...

Shamil

----- Original Message ----- 
From: "Ken Ismert" <KIsmert at texassystems.com>
To: "Access Developers discussion and problem solving"
<accessd at databaseadvisors.com>
Sent: Friday, October 21, 2005 10:25 PM
Subject: [AccessD] .NET Form Object Frameworks -- WAS: Data interface
Thebest way


>
> >I see now VBA/VB6-programming concept I called "DEEP-object concept"
> >(http://www.smsconsulting.spb.ru/shamil_s/articles/deepcnpt.htm)
>
> Shamil,
>
> Colby turned me on to your site some years ago. All I can say is that
> you were way ahead of the curve -- it even took MS 3 years to come up
> with a stable platform to run your concept.
>
> I too have dabbled with my own form management frameworks for Access. I
> got two running, the first a modestly complex, class-based framework
> that relied on sinking events (developed independently), and the second
> a stripped down, much-simplified framework based on interfaces. The
> interface framework managed not only Access forms, but Excel Userforms
> and standalone objects, as well.
>
> The shift in thinking was from a reactive style (respond to an event
> from something that already happened) to an active style (tell some
> object to do something with this information).
>
> One aim of the interface-based framework was to produce a more
> loosely-coupled system by moving parameters directly to the object,
> eliminating the reliance on any global objects (external form controls,
> global variables, functions and collections...). The other goal was to
> move away from the flakey form event system, and instead build framework
> "events" (in reality interface callbacks) on the much more reliable
> mechanism of object termination.
>
> I have thought of building a third framework that combined the best
> ideas of the first two, but have run into these problems:
> * Access Form objects have no parameterized constructor (a true
> Initialize event with a user-definable parameter list). Form_Open
> happens way too late for my purposes. (Maybe Access 2005 will correct
> this)
> * No easy way to deliver the framework. COM-based approaches would
> require Active-X dlls, developed in VB6.
>
> .NET seems to provide some answers:
> * VB.NET, C# and similar have the object sophistication to build a
> technically satisfying framework.
> * Packaging and installation appear to be simpler and more robust
> (although I can't say this firsthand)
>
> Some interesting thoughts on what such a framework should and shouldn't
> have:
> * Based in .NET
> * Works with Access via COM Interop to an Office Add-In.
> * Automates other form types, including Userforms and .NET forms.
> * Form Roles defined by the Interfaces they support.
> * Extensible by defining new Form Role Interfaces, and providing the
> support code to implement them.
> * Not driven by Form events. The form communicates to other forms in the
> framework via interfaces. Form events are considered private to the
> form, in that they don't drive inter-form communication. The form can
> use helper objects that sink form events and perform various services,
> including communication via the proper channels. These would be
> explicitly set up in the form.
>
> Of course, the larger question is, "why do this?". Maybe Microsoft will
> revive enough developer interest in its next release of Access to
> justify investing in such a framework.
>
> -Ken
> -- 
> AccessD mailing list
> AccessD at databaseadvisors.com
> http://databaseadvisors.com/mailman/listinfo/accessd
> Website: http://www.databaseadvisors.com