John W. Colby
jwcolby at colbyconsulting.com
Thu Mar 4 08:57:00 CST 2004
>Passes control to mtdLocalFormOpen on the form which: -sets form specific stuff like attached table, primary key, etc -handles form specific open args I guess my question is how does this "passes control" happen. If you are doing something like frm.SomeFunction IOW "calling" the function on the form, then you are "doing it questionably". The "right" way is to raise an event in the dclsFrm (whatever you call yours) after you finish processing each event. Then dimension your dclsFrm variable in each form Withevents. Next put event stubs in the form's built-in class which looks something like this: dim withevents fdclsFrm as dclsFrm private sub Open(Cancel as integer) set fdclsFrm = new dclsFrm fdclsFrm.Init Me, other parameters end sub 'THIS IS THE EVENT SINK FOR YOUR FORM CLASS' (RAISED BY YOUR CLASS) private sub fdclsFrm_BeforeUpdate(Cancel as integer) 'do whatever processing needs doing here AFTER your class processing end sub 'THIS IS THE EVENT SINK FOR YOUR FORM CLASS' AFTERUPDATE EVENT (RAISED BY YOUR CLASS) private sub fdclsFrm)AfterUpdate() 'do whatever processing you need to do AFTER your class processing end sub The event stubs for your class can be there if you need them or not if you don't need them. Remember that if you have an event stubs for form events in the FORM'S built in class they get control BEFORE your class, then your class, then your class raises its own event and transfers control back to whatever is listening to those events - typically but not always the form itself. I say not always because it is perfectly possible to listen to one form's events in another form, or even just in a class just sitting there listening. All that is needed is a variable dimensioned Withevents, and set to point to a specific instance of your dclsFrm. Then put event stubs in there for the events your class raises and it will gain control at some point in time. 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: Thursday, March 04, 2004 12:43 AM To: 'Access Developers discussion and problem solving' Subject: RE: [AccessD] Frameworks, what are they? 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 > -- _______________________________________________ AccessD mailing list AccessD at databaseadvisors.com http://databaseadvisors.com/mailman/listinfo/accessd Website: http://www.databaseadvisors.com