Stuart Sanders
stuart at pacific.net.hk
Wed Mar 3 23:42:46 CST 2004
Hehe Like I said I started moving it to a class driven system, and its far from finished, though I have it workable so to speak. Maybe I need to revisit your dclsFrm. When I started this it was a job just to get my head around some of the things that were going on. I do raise events in the class for the built in events.... Perhaps my terminology isn't up to scratch. Essentially what I do is the following. Form_OnOpen: calls class initialisation Class: -sets reference to self -registers with class collection -some other checks and settings -sets reference to parent -sinks form events -sinks standard buttons -scans form and sinks control classes -gets open args and puts in collection -checks if audit fields are present -other stuff Passes control to mtdLocalFormOpen on the form which: -sets form specific stuff like attached table, primary key, etc -handles form specific open args So what I meant was now the events are embedded into the class (sunk if you prefer). If a form current event occurs, then the class handles Form_Current first. Does its stuff and then passes control to the form if a custom form specific function for current event exists. Form_Current doesn't exist on the form. Sounds pretty much like what you do. As I said above, it is probably time to revisit dclsform. Stuart > -----Original Message----- > From: accessd-bounces at databaseadvisors.com > [mailto:accessd-bounces at databaseadvisors.com] On Behalf Of > John W. Colby > Sent: Thursday, 4 March 2004 12:53 PM > To: Access Developers discussion and problem solving > Subject: RE: [AccessD] Frameworks, what are they? > > > >Generally for events that I embed into the class I also add > a call to the > local form to a "local" event in case there is any form > specific stuff. So > the current event calls a function call on the form called > "FormLocalOnCurrent" or something like that. > > In my case I dimension my dclsFrm (my forms class) Withevents > in the form. > dclsFrmRAISES events in every event it sinks, which I call > AfterXXX where > XXX is the event name. AfterOnOpen for example. Any > parameters passed in > by the event sink from the form I pass right on out to the > AfterXXX event I > raise. Thus the form can sink my AfterAfterUpdate and perform any > processing it needs to do after my form class has done its processing. > > The thing to understand here is that if an event stub for an > event exists in > the form's built-in class, control is transferred there > FIRST, then to the > event stub in my class, and then (because I raise an event in my event > stubs) to the AfterXXX event in the form (if any). > > Having a form call an event in a form is "ass backwards" so > to speak. We > sink events from objects such as controls or forms. Those > objects never > call MY functions! My classes raise events as well and if > any other control > needs to sink those events then they do. By dimming my > dclsFrm Withevents, > the form can sink the events generated by my class if it > needs to do so. > > > John W. Colby > www.ColbyConsulting.com > > -----Original Message----- > From: accessd-bounces at databaseadvisors.com > [mailto:accessd-bounces at databaseadvisors.com]On Behalf Of > Stuart Sanders > Sent: Wednesday, March 03, 2004 10:43 PM > To: 'Access Developers discussion and problem solving' > Subject: RE: [AccessD] Frameworks, what are they? > > > I started moving to a class based framework in the latter part of last > year, and I had briefly at the time talked about it with > Robert when we > were working on LWS. I haven't worked on it much recently, but basic > functionality is added. > > Personally I think of a framework as a skeleton of what the app needs. > Much like a framework for a QA document, or a book. In the > book example > a framework (or layout) might contain a front cover, forward, > contents, > and chapters. If you are always doing the same kind of book you might > even include all the chapters (eg the Dummies books follow a framework > layout). > > In access (or other dev tool) the framework will mostly likely start > with standard forms/queries and tables that are in all apps > you deploy - > splash, menu, maintenance tools (compact and repair, backup, etc), > Sysvars like tables. > > It will also likely have forms and supporting tables and queries for > things that are used often. Perhaps things like registration forms, > security, etc. > > For class driven systems you would then start with basic > stuff and build > on it. For example to start with you make a form class > handle standard > events. You do this by calling the class in the form open event, it > then fires up and does whatever you have set it up to do. Typically > this would include embedding standard form events into the class. It > would also be extended to standard form objects (eg if you > often use an > undo button, save button, etc), and as you extend it you may have the > class scan for control types and add standard calls. > > Generally for events that I embed into the class I also add a call to > the local form to a "local" event in case there is any form specific > stuff. So the current event calls a function call on the form called > "FormLocalOnCurrent" or something like that. > > At this stage I have two form classes. One for lookup forms > and one for > standard forms. A lookup form is a simplified data > maintenance form for > tables that don't have any foreign keys or complex data. Usually just > lists, but may have multiple fields. The classes handle all standard > buttons, code behind most controls (beforeupdate etc) and some other > generic stuff. So if you look at the forms there is a lot less code > behind it doing the driving. In some cases just the calls to > the class > to initialise and terminate. > > I also have a bunch of other classes that are supportive in > nature. For > example there are classes for standard control like text boxes, combo > boxes, checkboxes etc that the form controls call when > initialising the > controls collection. There is a class for handling a list of strings > for things like form open arguments. (CustomerID=123456;Arg2=???) > > For controls, I have adopted some naming conventions, so text controls > would only get embedded if their name started with txt. A > text control > with txd is a date field, and has some other additional code for > calendaring etc. > > I've also created formtemplates for building a class driven > form. So I > copy the template and start dropping in controls. Basica form > functionality will be handled without additional work > > I've also moved over some personal dev tools such as a form maker for > building lookup forms. These get removed at deployment time but the > forms it creates stay. > > I will see about putting up a demo at some stage on just the class > related stuff I have done so far, as what I have done so far is likely > to be a lot simpler than older frameworks. Won't have time until at > least next week though. > > I would also be interested in seeing older frameworks. At this stage > mine draws heavily on examples by John from LWS and another > developer I > work with here occasionally (doesn't inhabit this list and doesn't use > access much anymore). Some things John does I have adopted (eg > registering classes into a collection - helps with debugging > particularly as class debugging can occasionaly get annoying, and > sysvars though I have adopted a slightly different approach) > > Stuart > > > -----Original Message----- > > From: accessd-bounces at databaseadvisors.com > > [mailto:accessd-bounces at databaseadvisors.com] On Behalf Of > > Robert Gracie > > Sent: Thursday, 4 March 2004 9:56 AM > > To: Access Developers discussion and problem solving > > Subject: RE: [AccessD] Frameworks, what are they? > > > > > > Ok so what are the basic "bones" if you will of a > framework? The basic > > skeleton I guess. > > > > Robert Gracie > > > > ************************* > > > > I am going to cc the list however. We have many developers who have > > developed their own framework. I have never seen anyone > > else's so I can't > > vouch for how complex they are now how conceptually similar > > to what I do, > > but if we address the list, perhaps we can get a discussion > > going on this > > stuff. > > > > John W. Colby > > www.ColbyConsulting.com > > > > -----Original Message----- > > From: Robert Gracie [mailto:Robert at servicexp.com] > > Sent: Wednesday, March 03, 2004 8:18 PM > > To: jcolby at colbyconsulting.com > > Subject: I have a question > > > > > > John, > > I have really appreciated the help over the last few months > > in regards to > > "DEEP" programming, your examples have been very helpful. I'm > > intrigued with > > "framework" idea however I have no idea where to get started. > > My question > > is; do you have any examples of a running "framework", or any > > books that > > explain how to set this sort of thing up? > > > > Thanks Again!! > > Robert Gracie > > > > > > -- > > _______________________________________________ > > AccessD mailing list > > AccessD at databaseadvisors.com > > http://databaseadvisors.com/mailman/listinfo/accessd > > Website: http://www.databaseadvisors.com > > > > > > -- > > _______________________________________________ > > AccessD mailing list > > AccessD at databaseadvisors.com > > http://databaseadvisors.com/mailman/listinfo/accessd > > Website: http://www.databaseadvisors.com > > > > -- > _______________________________________________ > AccessD mailing list > AccessD at databaseadvisors.com > http://databaseadvisors.com/mailman/listinfo/accessd > Website: http://www.databaseadvisors.com > > > > -- > _______________________________________________ > AccessD mailing list > AccessD at databaseadvisors.com > http://databaseadvisors.com/mailman/listinfo/accessd > Website: http://www.databaseadvisors.com >