John W. Colby
jwcolby at colbyconsulting.com
Mon Mar 15 20:33:41 CST 2004
Jim, > So you'll end up with lots of classes, unless I misunderstanding your intent. For example let's start with a base text box class. In a typical app, you can have text boxes that can be used for: 1. Text input 2. Input of a short date 3. Input of a short date and time. #2 and #3 are variations of #1 and contain some of the same behaviors and methods. So at the frame work level, I'm going to provide three classes or I'm going to do one class (text box) and overload it with properties to accomplish #2 and #3. But what your not doing is starting with #1, then creating #2 and #3 based on #1. Lets back up a minute and discuss this from a logical perspective. 1) Access has no inheritance. No overloading. No none of that stuff. 2) A text box has ... 66 properties THAT CAN BE SEEN FROM THE PROPERTIES DIALOG. So, as things CURRENTLY stand, you do NOT take a text box class and inherit it, or overload it or any of the rest of that stuff. However what you DO is take a text box and mess around with those 66 properties, some at design time only, others through code as well... and cause the text box to do various things for you. Are you happy? Most developers are happy and they go about their merry lives programming that set of 66 properties (of which some are actually events). That's all they have, that's all they're ever going to have. They never think to ask for more because as we all know, you can't inherit the text box so you can't extend it's functionality! WRONG! By building a class wrapper to the text box control object, I can add custom properties, methods and behaviors! Isn't that after all precisely what you are doing with the built-in class for forms? Writing custom code and event handlers to extend the built-in functionality of a generic form and turn it into Jim's super-duper wonder form for .... uh... taking orders. Of course I am not magically turning Access into FoxPro or .NET. I am NOT magically giving you inheritance or "overloading" or any of that stuff. This is ACCESS, NOT POXPRO. >I'm also assuming that it's not your intent to do a lot of instance specific behaviors. For example, if I want to add a popup calendar to all my text boxes that work with a date, I can't do that easily if I stuck with a single text box class and handled date/time issues at the instance level. That is EXACTLY MY INTENTION. Except that I intend to provide properties, methods and behaviors to any instance THAT NEEDS THAT. If a popup calendar floats your boat, build one and tie it in to the text box class. Have a UseCalendar property that you set the "turns on" using that calendar for exactly the instances where you want a calendar. However it is that you managed to program the text box to use the calendar in some form somewhere, that same exact code will work in the text box class. Except that once added to the class it is available to any text box anywhere in the app. Set your UseCalendar property and boom... that text box will use the calendar. This isn't magic, just engineering effort applied to the system rather than to one control on one form. Lets look at things a little differently! I lived in Mexico for 5 years. When you wanted a telephone line, the phone company took an order. They then (eventually) sent a crew to PULL LINE TO YOUR HOUSE. They did not put a cable full of 1000 wires down the street, they pulled ONE PAIR of wires for as far as they needed from the nearest switch to your house! AND BOY DID THEY CHARGE YOU A TON OF MONEY!!! Hello? Is anyone home? In the US, when people start building homes along a road, the phone company pulls a cable the size of your arm full of twisted pairs. When a development is built, the phone company pulls a cable the size of your arm to the development. The phone company in the US is to telephones what my framework is to Access development. The phone company in Mexico was the average Access developer pulling some service to exactly one control on one form, whenever they needed that service. And charging the client A TON OF MONEY FOR THE PRIVILEGE! Now, it is of course possible that there is ONE HOUSE way up on the top of a mountain, with a National forest all around it. There will never be a use for 1000 twisted pairs, and even in the US, the phone company will pull a FEW pairs of wires up there. I am not going to say that my framework will have every single service that anyone can throw at it. There are things that are needed ONE TIME and it makes no sense to put that in the framework. Do that ONE THING in that ONE FORM, embedded in that form's built in class and be done with it. If there is something that is just used all of the time, then YES, throw that in the framework. It will be available to every text box (or combo, or whatever) at all times. Turn it on/off (if you need to do so) on a case by case basis (or Application by application, or form by form). >If you do one class, you end up with a lot of code, some of which you might not always be need. Uh... yep! >It also increases the complexity of the text box class uh... yep! How many of those 66 properties of the text box do YOU actually program on the average text box instance? 10? Probably not even that. Are you saying that Microsoft should take out the rest of them "to reduce complexity" or so that there's not a lot of code that you don't use every instance? Or are you perhaps telling ME THAT I SHOULD NOT DO THIS but it is just fine that Microsoft does it? I used to have people tell me that "Oooooh your framework is more than 5 mbytes". ROTFL. I program Office for crying out loud. If I write code for Access, and use Word and Outlook, those three apps will take somewhere around 50 megabytes PLUS another 50 megabytes for Windows 2K PLUS another 5-15 megabytes for the application. And I am supposed to stay awake at night trying to figure out how I can reduce my bodacious 5 mbytes? I DON'T THINK SO! > Even with the limited OO capabilities of Access, there are still design issues in how to approach a framework that will have an impact on performance. The other issue you mentioned (object cleanup) also bears directly on performance, which is what initially prompted my comment. In the time that the hard disk takes on average to spin some piece of data under the heads (never mind moving the heads to that track, or reading it into memory) Access can completely clean up ALL of the hundreds of class instances that may be loaded!!!!! Cleanup doesn't involve getting out the vacuum cleaner and going after the dust mites in the corner. "unloading a class" doesn't mean putting it back out on the disk. Closing any recordsets (which have to be done anyway, framework or no), setting the pointers to objects to nothing, hands the memory back to the VB garbage collector and I am done. How long does it take to set 5 pointers to nothing? How long to set 10,000 pointers to nothing? At 2 gbit clock on an AMD processor... considerably less time than it takes you to blink your eyes. Stick around if you are interested in performance. I have never seen my framework impact performance in a meaningful way, but you will have a ringside seat to see for yourself. It is doing things that you are going to do anyway (in terms of behaviors) so it's not like you can avoid those penalties if you code that same behavior yourself. There are those who abandon Access because it doesn't do FoxPro (or .NET) like things. I am making no effort to prevent their leaving. I can't give you a framework that you can "inherit" and layer your own (framework) functionality on in a .NET like way. That simply isn't an option and it is not my fault, it is not a choice I make, it is not within my control. I just do what I can do with what I am given to work with. I do firmly believe however that what I am doing is waaaay more than "the average Access developer", even one who builds a library of functions to be called from event stubs in his forms. What I can do is to extend the functionality of any of the built in controls to provide consistent, available functionality that developers currently hand / hard code on a control by control / form by form basis, and make that functionality available anywhere it is needed, all of the time, just by setting properties. Kind of like the controls already do with the stuff they have built in. If that doesn't do anything for you I can appreciate that and encourage you to look elsewhere for your own solution. 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: Monday, March 15, 2004 2:58 PM To: Access Developers discussion and problem solving Subject: RE: [AccessD] Framework Discussion - Dependent Objects John, << Our wrapper allows us to do nothing more than add custom functionality to THAT wrapped object. >> So you'll end up with lots of classes, unless I mis-understanding your intent. For example let's start with a base text box class. In a typical app, you can have text boxes that can be used for: 1. Text input 2. Input of a short date 3. Input of a short date and time #2 and #3 are variations of #1 and contain some of the same behaviors and methods. So at the frame work level, I'm going to provide three classes or I'm going to do one class (text box) and overload it with properties to accomplish #2 and #3. But what your not doing is starting with #1, then creating #2 and #3 based on #1. I'm also assuming that it's not your intent to do a lot of instance specific behaviors. For example, if I want to add a popup calendar to all my text boxes that work with a date, I can't do that easily if I stuck with a single text box class and handled date/time issues at the instance level. In that case, I should not have bothered with a framework at all, but instead create tools to manipulate instance specific items. In fact now that I say that, I'm wondering how you would roll out new versions of the Framework. If I as a developer have no choice but to modify your classes (because it's a single layer) and you distribute a new version, how can I easily implement it? The only alternative is to provide a large number of hook procedures that your class calls to find out if the developer wants to change anything. Anyway, excluding the last two options, this means that if you go the three class route, you are coding the "text box" behavior (i.e. background color when active) in three places, thus eliminating some of the benefits of doing it in the first place. If you do one class, you end up with a lot of code, some of which you might not always be need. It also increases the complexity of the text box class. Even with the limited OO capabilities of Access, there are still design issues in how to approach a framework that will have an impact on performance. The other issue you mentioned (object cleanup) also bears directly on performance, which is what initially prompted my comment. Jim (315) 699-3443 jimdettman at earthlink.net