Haslett, Andrew
andrew.haslett at ilc.gov.au
Sun Mar 7 21:59:12 CST 2004
;=) Nope - standard issue in .Net. Along with 'Self Documentation...' Pretty easy to pick up.. -----Original Message----- From: John W. Colby [mailto:jwcolby at colbyconsulting.com] Sent: Monday, 8 March 2004 2:23 PM To: Access Developers discussion and problem solving Subject: RE: [AccessD] Your favorite control behavior >The ability to create custom controls (as classes) and expose custom properties and methods is awesome in .Net, and something I've used extensively throughout my applications. And don't you worry that the "developers" out there won't understand your stuff? <grin> John W. Colby www.ColbyConsulting.com -----Original Message----- From: accessd-bounces at databaseadvisors.com [mailto:accessd-bounces at databaseadvisors.com]On Behalf Of Haslett, Andrew Sent: Sunday, March 07, 2004 10:18 PM To: 'Access Developers discussion and problem solving' Subject: RE: [AccessD] Your favorite control behavior Yep - I've been dev. In Access since 1.1 and love it, but tend to do very little consulting these days, simply as I find distributed applications and the related new technologies more interesting. I've been a little hesitant to jump on the bandwagon as I've always felt the form and report designer in Access was about as good as it gets, however Visual Studio.Net compares nicely. The ability to create custom controls (as classes) and expose custom properties and methods is awesome in .Net, and something I've used extensively throughout my applications. Interested to read your comments about the database element. I'm an MCDBA myself and have found the new objects in .Net used to connect to data stores, a huge improvement over previous versions. You must remember that the data stores for your applications are not 'embedded' in your application as they are in Access, and so obviously aren't going to have the same 'native' functionality, however this is inherent about distributed applications. To make the framework flexible, allowing multiple data sources, such as DB/XML/Web Services/etc -> that sort of functionality is simply not possible.. If that is what you're getting at, it only takes a bit of getting used to and you come to grips with disconnected data connections. I guess it was a little easier for me as I've developed web apps for quite some time and this methodology has been required throughout. I also imagine it would take a little getting used to binding your controls to data-sources, which is inherently easier in Access due to its embedded data-source, but again it's necessary (and often an advantage) in disconnected apps and there are tools provided (in VS.Net) to help with this process. I will continue to follow any framework discussions with interest. I'm also looking forward to upcoming versions of Access where perhaps the 'best of both worlds' will combine - even though I sense many here are not.. Cheers, Andrew -----Original Message----- From: John W. Colby [mailto:jwcolby at colbyconsulting.com] Sent: Monday, 8 March 2004 1:24 PM To: Access Developers discussion and problem solving Subject: RE: [AccessD] Your favorite control behavior Andrew, Yes, I am (slowly) learning .net. It's OO stuff is enough to make me drool. Unfortunately it's database stuff is weak and I am a database developer. Stick around (if you are an Access developer) for the framework discussion. Access' inheritance is non-existant so we use workarounds. If I could just inherit the form class and add my stuff I probably would do that but I can't. And of course controls don't have a class at all. Look in .net and a control is just a class that you can inherit like any other class. NICE!!! Lacking that in Access, classes out in a lib is a poor man's substitute and is what I am up to. John W. Colby www.ColbyConsulting.com -----Original Message----- From: accessd-bounces at databaseadvisors.com [mailto:accessd-bounces at databaseadvisors.com]On Behalf Of Haslett, Andrew Sent: Sunday, March 07, 2004 9:41 PM To: 'Access Developers discussion and problem solving' Subject: RE: [AccessD] Your favorite control behavior I always thought it was "I couldn't care less". Anyway, very interesting discussion. John, not sure if you've looked into yet, but the .Net languages (and many other OO languages I presume) will provide you with a lot of support for what you are trying to implement with your framework. Inherting your pages / controls from a base class will be ideal to 'inherit' common functionality that it seems you are doing. Custom controls (reusable) alse offer the capabilities you are creating with your framework. I haven't looked in detail at your framework or anything - just been browsing these discussions, but was interested to know if you've looked into .Net yet.., as I think you would find it quite interesting. Cheers, A -----Original Message----- From: John W. Colby [mailto:jwcolby at colbyconsulting.com] Sent: Monday, 8 March 2004 12:19 PM To: Access Developers discussion and problem solving Subject: RE: [AccessD] Your favorite control behavior >Correct me if I'm mistaken, but my understanding is that a form has >it's own class which you can multi instance in various ways and in which you can create property procedures and do any thing else one can do in a class of your own. It sounds not like you are creating a form class but a separate class to shadow the form class. Yep, you are correct. >The downside is needing to know the name of a control in order to be >able to operate with it. To program certain functionality (such as passing in the table / field / form to a combo for NotInList) that is correct. >The advantage of hooking up all default behaviors with a function is >that you can pass the procedure a reference to the actual control for which the event is triggered so there is no need for collections or code to run on the form open event. I see no advantage there. My form class scans all of my controls and loads a class for each control. That class hooks up all the functionality for them. I don't have to "make sure" I have cut the control from the right place so that stuff is in the event properties. >Every copy/paste of a control is automatically hooked up to the >standard events without ever writing any code except the single function procedures that all copies of the control trigger. So you have replaced writing a few lines of code in the Form's Open (standard, can be cut and pasted) with dozens of cuts and pastes of controls onto the form? Hmmm..... I can definitely see how this might be better.... <grin> >You can override the 'inherited' behavior by changing the function, >writing a specific event procedure or passing in one or more additional optional parameters. Of course you can. So can I using my framework and control classes. >Correct me again if I'm mistaken, but this facility to hook up events >has been around since Access 1 whereas WithEvents is somewhat newer and more esoteric and less universally understood or used. That's like saying "The car has been around a lot less time than the horse so why are we using a car". Sure, Withevents were not around when Access 1.0 came out, and of course this is not applicable to 1.0. More powerful tools are handed to us year after year. To say I am not going to use it because it wasn't available in 1.0 is silly and prevents adapting some very powerful tools. Jurgen, I could care less whether you want to use this stuff. I could care less whether you love hooking functions straight up to the event property. That is an option, and if that is the tool you choose to use, that is your business. I have explained to you why I don't touch that stuff, and why, when I have to take over an app where the previous developer uses that method it pains me greatly. I used to use it, don't get me wrong, it's just that there are tons of disadvantages and only one advantage, your "cut and paste" advantage. That "cut and paste" advantage isn't sufficient in my mind to overcome the disadvantages. In fact that advantage has been neatly replaced by Withevents in classes! You have a SINGLE function that you hook to a property, and you have a bunch of functions that you hook to a bunch of properties. I have a class that I pass a control to. I sink the events in that class, then call various functions of the class from those events. The results are similar, but not identical. I can for instance, turn on/off the behaviors using sysvars. My good friend William Hindman was using some stuff of mine and didn't like some specific things I was doing. I simply "switched it off" for him. Nothing more than "go in the sysvar table and set this sysvar = false. His system didn't use that behavior anymore. Try THAT with your method. A framework is waaaay more than just a function hooked to an event, or even a bunch of functions hooked to a bunch of events. It is a whole system that works together. My control classes talk to the form class. The form class loads SysVars that turn on and off functionality of the framework. I can override a given functionality for the entire application, or just for a given form in the application. The control classes "talk to" the form class and ask whether they should exhibit this behavior? The control class simply doesn't care whether the behavior is turned on / off for the entire application or just this form, all they care about is that they are supposed to exhibit the behavior THIS TIME, RIGHT NOW. Tomorrow the user might want the behavior and I go turn it on using a SysVar. TRY THAT with your "cut and paste" stuff!!! >Like Arthur, it looks to me like you write a great deal more code than >the one line each of us uses to hook a control to a common not in list procedure because you need to write and maintain the framework. You are 100% correct. I do write a whole lot more code than you do. In fact I write almost EXACTLY the same code you do, I just make it a part of a whole system rather than an isolated thing that happens. The "way more code" is the stuff required to tie it in and make it a system. When I design a form I don't "cut and paste" a bunch of controls so that they get hooked up properly. My form class loads control classes that hook everything up for me automatically. Whether I have one or a hundred combos on a form, every one can, if it needs it, have any of the various behaviors that the combo class provides. Why in the world would I go somewhere, "cut a control" and paste it in the form a hundred times? Furthermore I can take ANY form, load a form class in that form's Open and have all of my stuff just automatically applied to all of the controls on that form! All the combos suddenly know how to do combo stuff, all the text boxes suddenly know how to do text box stuff. If a given combo needs NotInList (and MANY don't), then a single line of code passes in the correct table / field / form for that combo to know how to do it. Try THAT with your "cut and paste" stuff! I seem to remember butting heads with you in the past. You were always about "the last ounce of (application) speed", and I simply don't care about that last ounce. I am more about speed of development and ease of maintenance. Your "cut and paste" does allow lightweight forms. I could care less. If that is what this is all about, I will hand you your "speed advantage" and you can walk away the winner. I will take my speed of development and ease of maintenance and I too will walk away a winner. I understand what you are doing, I have done it that way in the distant past. Listen to what I am trying to explain where frameworks are concerned, read it, UNDERSTAND it (ALL OF IT), and then if you still love your "cut and paste" stuff... "may the force be with you". And may I never have to maintain your apps! <grin> John W. Colby www.ColbyConsulting.com -----Original Message----- From: accessd-bounces at databaseadvisors.com [mailto:accessd-bounces at databaseadvisors.com]On Behalf Of Jürgen Welz Sent: Sunday, March 07, 2004 6:01 PM To: accessd at databaseadvisors.com Subject: RE: [AccessD] Your favorite control behavior Correct me if I'm mistaken, but my understanding is that a form has it's own class which you can multi instance in various ways and in which you can create property procedures and do any thing else one can do in a class of your own. It sounds not like you are creating a form class but a separate class to shadow the form class. The downside is needing to know the name of a control in order to be able to operate with it. The advantage of hooking up all default behaviors with a function is that you can pass the procedure a reference to the actual control for which the event is triggered so there is no need for collections or code to run on the form open event. Every copy/paste of a control is automatically hooked up to the standard events without ever writing any code except the single function procedures that all copies of the control trigger. You can override the 'inherited' behaviour by changing the function, writing a specific event procedure or passing in one or more additional optional parameters. Correct me again if I'm mistaken, but this facility to hook up events has been around since Access 1 whereas WithEvents is somewhat newer and more esoteric and less universally understood or used. I suspect that developers coming from a Visual Basic background are less familiar with the advantages of this approach, particularly when they bemoan the lack of control arrays. I suspect this facility is the reason that control arrays were never needed in Access. Like Arthur, it looks to me like you write a great deal more code than the one line each of us uses to hook a contol to a common not in list procedure because you need to write and maintain the framework. Ciao Jürgen Welz Edmonton, Alberta jwelz at hotmail.com -- _______________________________________________ AccessD mailing list AccessD at databaseadvisors.com http://databaseadvisors.com/mailman/listinfo/accessd Website: http://www.databaseadvisors.com IMPORTANT - PLEASE READ ******************** This email and any files transmitted with it are confidential and may contain information protected by law from disclosure. If you have received this message in error, please notify the sender immediately and delete this email from your system. No warranty is given that this email or files, if attached to this email, are free from computer viruses or other defects. They are provided on the basis the user assumes all responsibility for loss, damage or consequence resulting directly or indirectly from their use, whether caused by the negligence of the sender or not. -- _______________________________________________ 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 IMPORTANT - PLEASE READ ******************** This email and any files transmitted with it are confidential and may contain information protected by law from disclosure. If you have received this message in error, please notify the sender immediately and delete this email from your system. No warranty is given that this email or files, if attached to this email, are free from computer viruses or other defects. They are provided on the basis the user assumes all responsibility for loss, damage or consequence resulting directly or indirectly from their use, whether caused by the negligence of the sender or not.