John W. Colby
jwcolby at colbyconsulting.com
Wed Mar 3 22:53:23 CST 2004
>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