Jim Dettman
jimdettman at earthlink.net
Fri Apr 7 11:21:26 CDT 2006
John, It's only silly to say if your trying to solve all those other problems. And while a framework does solve a lot of problems, it also creates some of it's own; performance, complexity, class design, etc Frameworks are not the pancrea that everyone believes. Jim. -----Original Message----- From: accessd-bounces at databaseadvisors.com [mailto:accessd-bounces at databaseadvisors.com] On Behalf Of John Colby Sent: Friday, April 07, 2006 9:47 AM To: 'Access Developers discussion and problem solving' Subject: Re: [AccessD] Setting Default control sizes in advance >No need to spend hundreds of man-hours building a framework! <vbg> LOL, what a silly thing to say. There are hundreds of reasons to spend hundreds of hours building a framework, this is just one of them. Now, answer the question for EXISTING projects. My answer works for ALL of my projects because ALL of my projects use my framework. Not only can I do this if I want to, I can and do have combo double-click and notinlist event handling, when forms pop up for my combo double click it can take you to the exact record that the combo is currently displaying (to edit it for example). When handling the NotInList event and popping up a form to add new data, it can find the control that the typed in data belongs in and place it in that control so the user does not have to type it over again. My forms can have a record combo. Copy and paste a combo and a text box onto the form from my template form, bind the control to the autonumber PK and set the combo's data and the combo will just function as a record selector, automatically. Set a sysvar and change the date format in every text box that needs the date formatted in a specific manner. Do the same to set a date mask. How about dbl-click to open a calendar, which automatically passes back the calendar value to whichever text box opened the calendar? My framework does that. Need a form to have automatic OpenArgs parsing and preparation for use? My framework has that. I can open a form (as we discussed in this email group a few weeks ago) and just pass in Openargs which the opening form automatically applies to its properties. Pass in "Allow Edits=True;Allow Deletions=False;AllowAdditions=False;" as the Openargs when you open a form and it sets itself up as an edit only form. Pass in "Data Entry =True,Allow Edits=True" as the Openargs when you open a form and it sets itself up as a data entry form. JUST THAT SIMPLE. Do YOUR forms allow you to do that? How about the ability to automatically requery dependent objects when something changes? My framework has that. I can, in ONE line of code per dependent item, tell combos, forms and lists to be requeried when another object changes state. Not only that, but if THAT "dependent" combo has combos (or forms, or lists) dependent on it's value, they can be requeried automatically. Using this functionality, I can if I want to have another FORM requery itself when OnCurrent of the existing form fires. ONE LINE OF CODE to tell the current object that some other object is dependent on it and to requery that object if the current object changes. Yep, my framework does that. Want to be able to make a form editable by one group of people but not another group? How about hide / unhide a command button, tabs on a form or other controls based on what group (supervisors?) a person belongs to. My framework does that. Ever needed to have information specific to an application displayed on a report? Company address / phone / etc? Application SysVars. Add a new SysVar record in the Application SysVar table and it is instantly available to the application for whatever it needs. It takes me oh.... About 2 seconds to add a new sysvar. I know people who add new fields in a table to do this!!! HUNDREDS OF REASONS to build a framework. My framework allows me to do things in 10 minutes when setting up a form that will take you HOURS for each and every form you design. OR... You just don't give your client that functionality. There are those that program the same solution over and over and over and over (and over) and then there are those that use (at the LEAST) a library (which is a casterated framework), or if you really want to work efficiently, you use a framework. Sorry, but to say "No need to spend hundreds of man-hours building a framework" displays a huge ignorance of what can be done if you use one. And the sad part of that statement is that I do nothing more than anyone else does really. I discover a need, I design a solution. But instead of placing the solution in the application (if the solution generalizes) I do it in the class for the object that needs the solution. DblClick and NotInList for the combo goes in the combo control class. I NEEDED THAT, I designed it ONCE, I placed it in the proper class, and now it is available to every front end I develop. I needed SysVars. I designed a class system to do that and now I can have none, one or a dozen SysVar tables. My framework always has one and my app always has one. The framework automatically loads and initializes them on the Framework Init. And I can build others for special purposes as needed. ?"No need to spend hundreds of man-hours building a framework"? I sure can't think of any reasons to do so,but then I'm not very imaginative. <grin> John W. Colby www.ColbyConsulting.com -----Original Message----- From: accessd-bounces at databaseadvisors.com [mailto:accessd-bounces at databaseadvisors.com] On Behalf Of Heenan, Lambert Sent: Friday, April 07, 2006 9:45 AM To: 'Access Developers discussion and problem solving' Cc: 'Arthur Fuller' Subject: Re: [AccessD] Setting Default control sizes in advance There's actually a much simpler way to do this, and it only requires you use the AutoFormat feature. Here's the drill: Design a form with the font and colors and whatever that client1 want, and then save it as an autoform form design, calling the style "Client1" (you do that by selecting AutoFormat from the Format menu and then hit the 'Customize' button. Then do the same for Client2, design a from to suite that need and save it as an autoformat style. These form styles are global to Access. You will see them available in every application you work on. Now, whenever you want to build a form for Client1 open up their application, select one of the existing forms, and choose the client1 style from the AutoFormat dialog. You do this because, having made a choice in the AutoFormat dialog, that choice becomes the default style that will be used by the form wizards. Then when working on Client2's application, do the same thing - select their style from the Autoformat dialog, and presto, you can build forms to their liking with the wizards. No need to spend hundreds of man-hours building a framework! <vbg> Lambert -----Original Message----- From: accessd-bounces at databaseadvisors.com [mailto:accessd-bounces at databaseadvisors.com] On Behalf Of John Colby Sent: Friday, April 07, 2006 2:05 AM To: 'Access Developers discussion and problem solving' Subject: Re: [AccessD] Setting Default control sizes in advance Arthur, >Solutions requested! >Client A wants 12 point Arial everywhere. >Client B wants 10 point Times Roman everywhere. Frameworks and SysVars. I have not done that specific thing, but since my framework loads a class for each form instance and each control type, for each instance of that control type, it would be trivial for the text class to set the font/pitch etc as the class loads. That is the framework part. SysVars say "for this FE make this property this specific value". In other words, I can have a SysVar named "CtlTxtBoxFont" the value of which is Ariel, and another SysVar named "CtlTxtBoxFontPitch" the value of which is 12. The clsFrm would have to be programmed to know about this SysVar, and load that pair of SysVars,into its SysVar collection (each form class has a collection to hold SysVars specific to that form), and then the clsCtlTxtBox would have to ask the form what Font and Pitch to use. I actually do this kind of thing, and in fact have the ability to have SysVars specific to a particular form. I do this by having a generic SysVar such as CtlTxtBoxFontPitch which is set to 12 in the SysVarTable. When the form loads it looks for SysVars with its (the form's) name in the SysVarName, for example frmClientCtlTxtBoxFontPitch. Since When the frmClient loads it scans all the SysVars looking for its name in every SysVar. If it finds any it strips its name out and "overrides" the generic value with the value specific to itself. Thus while all forms will load CtlTxtBoxFontPitch and end up with a value of 12, frmClient may simply have so many controls that it isn't feasible to use a 12 pitch so I can set frmClientCtlTxtBoxFontPitch to 10 and only frmClient will use a 10 pitch font. I actually have this capability set up in my framework (SysVars and the ability to override them for any specific form). For me it would be almost trivial to set up to do something like you propose. I did a similar thing with date formats. Using DAO I drill down to discover what type of data is being pulled out (for text boxes specifically). If the data type is a date, I have a default date format defined in a SysVar. Thus I can set a consistent date format via a sysvar, and if the client wants a different data format, it is a simple matter of changing a single sysvar. A framework is a very powerful concept and once set up and functioning can allow implementation of behaviors that vary from front end to front end and client to client. Sysvars allow the programmer to have "steering logic" in the application. With default values in the SysVars you can have your applications "just work" a specific way, and yet easily override that for a specific reason, even down to the form level if desired. John W. Colby www.ColbyConsulting.com -- AccessD mailing list AccessD at databaseadvisors.com http://databaseadvisors.com/mailman/listinfo/accessd Website: http://www.databaseadvisors.com