Arthur Fuller
artful at rogers.com
Tue Mar 9 13:44:29 CST 2004
I could be of some help in the move to SQL too, JC. -----Original Message----- From: accessd-bounces at databaseadvisors.com [mailto:accessd-bounces at databaseadvisors.com] On Behalf Of John W. Colby Sent: Monday, March 08, 2004 7:29 AM To: Access Developers discussion and problem solving Subject: RE: [AccessD] Your favorite control behavior Are you a proficient programmer? If so I'd love to work with you, just follow the Framework discussion as it unfolds. I have just about decided to rebuild my own framework for the 3rd time (making it a 3rd generation design ;-) and will be doing so via this discussion. John W. Colby www.ColbyConsulting.com -----Original Message----- From: accessd-bounces at databaseadvisors.com [mailto:accessd-bounces at databaseadvisors.com]On Behalf Of Mike & Doris Manning Sent: Monday, March 08, 2004 9:01 AM To: 'Access Developers discussion and problem solving' Subject: RE: [AccessD] Your favorite control behavior I'm pretty SQL savvy... I'd be interested in helping you out. Doris Manning Database Administrator Hargrove Inc. www.hargroveinc.com -----Original Message----- From: accessd-bounces at databaseadvisors.com [mailto:accessd-bounces at databaseadvisors.com] On Behalf Of John W. Colby Sent: Monday, March 08, 2004 7:45 AM To: Access Developers discussion and problem solving Subject: RE: [AccessD] Your favorite control behavior You are correct however I can't efficiently do that since I don't understand the "working with" SQL Server enough to get anywhere. I have a client who is moving one of my apps to SQL Server. It would be nice to be able to get the framework "SQL Server compliant" whatever that may mean. Unfortunately they are using A2K and will continue to do so for quite some time I'm afraid. And I squeeze every bit of "interface" out of Access using things like queries that reference controls on forms, queries that reference my own custom VB (or for that matter Built-in) functions. Both of these are no-nos when working with SQL Server. So it is very much a combination of making the framework itself "data store independent" as well as MY learning how to replace what I do with what will work with SQL Server (or rather non-jet) data stores. For BOTH, I could use an expert in squeezing the last ounce of "interface" out of non-Jet data stores. 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: Monday, March 08, 2004 1:56 AM To: 'Access Developers discussion and problem solving' Subject: RE: [AccessD] Your favorite control behavior >>I'd LOVE to work with an extremely competent SQL Server developer / programmer in >> doing this though since I am going to need this functionality but >> don't know SQL Server that well I don't think its SS as much as interfacing with the (OLEDB) driver used to communicate between Access and SQL. That's where your equivalent recordset behaviours come in. Unless youre talking about wrapping your functionality in Stored Procs using a disconnected framework... -----Original Message----- From: John W. Colby [mailto:jwcolby at colbyconsulting.com] Sent: Monday, 8 March 2004 4:26 PM To: Access Developers discussion and problem solving Subject: RE: [AccessD] Your favorite control behavior The answer to ADO is yes... with the exception of the form RecordsetClone property which is by definition DAO. I use ADO exclusively in my current framework except for the recordsetclone stuff. I use recordsetclone to get a handle to the current recordset, as well as the current position of the form (what record is displaying) and use that to "move" the form to display a different record etc. As for unbound, hmmm... it probably could. I use a lot of tricks in my framework such as looking at the field that the control is bound to discover the field name, and now that I know how to do so (using DAO) drilling clear down to the table name and field name. So the answer to that is probably, but you might lose a lot of neat functionality. I'd LOVE to work with an extremely competent SQL Server developer / programmer in doing this though since I am going to need this functionality but don't know SQL Server that well. John W. Colby www.ColbyConsulting.com -----Original Message----- From: accessd-bounces at databaseadvisors.com [mailto:accessd-bounces at databaseadvisors.com]On Behalf Of Jim Lawrence (AccessD) Sent: Monday, March 08, 2004 12:09 AM To: Access Developers discussion and problem solving Subject: RE: [AccessD] Your favorite control behavior Hi John: I have always liked your framework structure concept. I have not been too interested in pursuing that application deployment as, and do not take this the wrong way, most of my work is with SQL server BEs and, correct me if I am wrong, but at first blush, your framework is designed to manage 'bound' DAO programs. My apps may or may not bind the recordsets and these recordset are used to populate the forms...one step removed. Also, I use ADO almost exclusively. Does your framework handle or can be made to handle ADO and Unbound forms? (but bound (qualified) recordsets) Jim -----Original Message----- From: accessd-bounces at databaseadvisors.com [mailto:accessd-bounces at databaseadvisors.com]On Behalf Of John W. Colby Sent: Sunday, March 07, 2004 6:54 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 -- _______________________________________________ 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. -- _______________________________________________ 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