John Colby
jwcolby at ColbyConsulting.com
Fri Apr 7 17:33:16 CDT 2006
> I was thinking more in terms of execution speed. For the example at hand (and it's not a great example, but you'll get the point), if I have an app that doesn't need the point size modified ever, then anything that executes to maintain that feature is just a waste. Depending on the framework and what it provides, it can be the difference between a sluggish app and one that is snappy. I understand that concern. What I can tell you though (from extensive testing) is that it takes under 1/2 millisecond to load an "average" class instance. Thus you can load 2000 class instances in under a second. A lot of what a class does it does as it loads - modifying how things work etc. The other thing to understand is that you can, using the same SysVars I have been discussing, turn on/off functionality, either for the entire FE, or on a form by form basis. IOW I can tell the APPLICATION to use date formatting. What does this mean? In order to do date formatting, DAO has to drill down into the bound recordset and discover the data type for specific types of controls. Obviously it only does this for forms that can possible display a date, which means (in my framework) only text boxes. The form has a control scanner. When the scanner function is called, it checks whether THIS FORM is supposed to use date formatting. If so it starts scanning for controls and loading a class for those controls for which a class exists (most). As it discovers TEXT BOXES, it discovers which field the text box is bound to and drills down to discover the data type. If the data type is a date, then it reads the APPLICATION SysVar for date formatting and plugs it in to the property of that text box. The point of all this is that yes, the framework (form class and text box control class) have to do this processing, but it is focused. ONLY if the APPLICATION date formatting is turned on and ONLY if this form is supposed to format dates, and even then only specific controls. Because I cache all framework and Application SysVars in a class, accessing one or all of the variables is virtually instantaneous. >Frameworks are great and do solve a lot of problems, but I've found that you need to be very careful not to overbuild. What you have to be careful of is that you have switches (SysVars) that entirely turn on / off the features. Having an actual framework though means that the switches are loaded at Init of the application. I typically have 50 to 100 Application SysVars and 50-100 Framework SysVars. The load time for that is negligible. As any given form loads, it searches all of the APPLICATION SysVars for the form's name in the SysVar name. Again, if there are 50-100 SysVars, the var names are about 10 - 20 characters long plus the length of the form name so again, the time to find form specific SysVars is negligible. I have a function where I "define" which SysVars are required for a form. As I build new form functionality that requires a SysVar, I go to that function in the form class and "load" that SysVar into a SysVar collection in the form class itself. Thus, like the framework itself, by the time the form finishes loading it has its own private collection of exactly and only the switches (SysVars) that apply to it. All of this kind of processing may sound like it slows things down but in fact it speeds things up. SysVars, once loaded by the Framework are never again loaded from the disk. Forms look in the framework SysVar collections as they load. Code functionality looks in the form's SysVar collection to determine what the form needs to do. >Of course the trade-off is that it takes me a little more work to hook things up. I don't know what you have to do to hook things in but all I have to do is turn on / off a SysVar. Is your method truly just a "little" more work? At any rate, my purpose is not to "convert the heathens". I simply find that having stuff loaded and ready, with "services" available to the application is a very powerful concept. There are many people that simply aren't capable of implementing their own framework, and to them I suggest learning about libraries and at least do that much. Classes provide an additional level of "setup/cleanup/encapsulation" that is very powerful. Until I actually used them I could not understand why or how I would use them. Once I started using them I cannot imagine how I could survive without them. I still have modules of course, but any "system" now goes in one or more classes. John W. Colby www.ColbyConsulting.com -----Original Message----- From: accessd-bounces at databaseadvisors.com [mailto:accessd-bounces at databaseadvisors.com] On Behalf Of Jim Dettman Sent: Friday, April 07, 2006 3:47 PM To: 'Access Developers discussion and problem solving' Subject: Re: [AccessD] Setting Default control sizes in advance John, <<Performance - I will argue that one since the total time to load all of the classes I mention is under a second at framework init and well under 1/2 second for all of the classes for a given form, even complex ones.>> I was thinking more in terms of execution speed. For the example at hand (and it's not a great example, but you'll get the point), if I have an app that doesn't need the point size modified ever, then anything that executes to maintain that feature is just a waste. Depending on the framework and what it provides, it can be the difference between a sluggish app and one that is snappy. The general problem with frameworks is that you want to use it on everything (and there in lies it's power). But as a result, as you toss in anything you need now and might need in the future, it just becomes more and more bloated for each application in general. Office is a great example of how that gets out of control; at one point, something like 90% of the features in office were never used by most people. That 90% to them was just a waste. Microsoft combated this to a certain extent by only installing a limited feature set and having an install on the fly if it's needed, but they still waste a lot of cycles checking the state of things. Frameworks are great and do solve a lot of problems, but I've found that you need to be very careful not to overbuild. In regards to Access, I have many of the same features that you have, but their in small discrete modules that I can load into an app as needed, keeping it somewhat light weight. Of course the trade-off is that it takes me a little more work to hook things up. With VFP, I use a full blown framework with a truck load of features and because it is a compiled language, the performance hit isn't that great and I can get away with it. But I'd hate to use something like that with Access. 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 1:09 PM To: 'Access Developers discussion and problem solving' Subject: Re: [AccessD] Setting Default control sizes in advance Uhhh, yep. Of course I wasn't trying to solve all of those other problems. I solved one, then another then another etc. I started with a simple library like many developers do. It was truly only when I finally figured out Withevents (which REQUIRE classes) and now had a grasp of classes (as implemented in Access anyway), that the framework really began to happen. Complexity, yes of course. Classes, yes of course. Performance - I will argue that one since the total time to load all of the classes I mention is under a second at framework init and well under 1/2 second for all of the classes for a given form, even complex ones. What a lot of people don't know is that the CODE for a class only loads once. The entire class loads the first time it is used, and remains in memory after that so it isn't like if I load a form with 40 controls I have to LOAD the 40 control classes over and over again. The form class loads once, the combo class loads once, the text box class loads once, then the VARIABLE/CONSTANT portion is created for each class instance. Frameworks are a tool, a very powerful tool, but certainly not a panacea. OTOH, cutting and pasting code into forms or modules in each FE is no panacea either. There are developers out there that only work on a single FE. A framework is much less useful there since you don't need to apply the same functionality to a second application. For anyone maintaining more than one application, a "library" is almost a requirement, and a framework is simply the next (HUGE) step up in functionality. John W. Colby www.ColbyConsulting.com -----Original Message----- From: accessd-bounces at databaseadvisors.com [mailto:accessd-bounces at databaseadvisors.com] On Behalf Of Jim Dettman Sent: Friday, April 07, 2006 12:21 PM To: 'Access Developers discussion and problem solving' Subject: Re: [AccessD] Setting Default control sizes in advance 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 -- 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