Bill Benson
bensonforums at gmail.com
Sun Mar 23 21:50:18 CDT 2014
BTW As a diatribe against unbound controls, I like it. I just wish I could get away with all my laziassness using bound controls, but they never work for me because I never seem to know how to create an updateable recordset the way I do things. Like have large flat-ish tables wherein I need to create group by queries to present simplified information for them to cherry-edit values on unbound forms, then push the changes back to the main tables. No doubts about it John, you are the professional's professional. I am just a hack. Not proud of it, and maybe someday someone will pay me to learn better techniques. If they don't I will just do what I have time to do. BB -----Original Message----- From: accessd-bounces at databaseadvisors.com [mailto:accessd-bounces at databaseadvisors.com] On Behalf Of Jim Lawrence Sent: Sunday, March 23, 2014 10:35 PM To: Access Developers discussion and problem solving Subject: Re: [AccessD] Unbound Form Check For Changes Hi John: I see no flaw in your argument other than, if you don't already have classes built and tested, it can be a bit of over-complexing a rather simple requirement. For larger projects, a healthy code library, at your disposal, is of course now a requirement. Jim ----- Original Message ----- From: "John W Colby" <jwcolby at gmail.com> To: "Access Developers discussion and problem solving" <accessd at databaseadvisors.com> Sent: Sunday, 23 March, 2014 6:54:51 PM Subject: Re: [AccessD] Unbound Form Check For Changes LOL, but you have already made clear that you see no benefit to classes in general. Classes allow us to use Object Oriented programming techniques. The programming language / environment is irrelevant, that is their purpose. OO is about storing the code and data for a given object in a single location, wrapping behaviors and data together. If you are not using classes than you have scattered code to hell and back to handle the objects. The events fire for a text box. Where is the code to handle that? In the form's class? But the form's class is supposed to be modeling the FORM'S properties and events. Now it is handling every event for not only itself, but for every control that it contains. And anything else you want to stuff there!!! If you design a table, do you place all the information about the client and their cars and their invoices and their orders all in the client table? Obviously not, you create a table for each item. You are MODELING objects, with each object having its own table. In programming, I (personally) model each object. OO teaches me that is the "best practices" way of doing programming. Each function is supposed to do one thing. Each class is supposed to model one object. The form's module is a CLASS!!! It is supposed to model a specific form, NOT a bajillion other things as well. Microsoft, knowing full well that the average user will have no programming experience, ALLOWS you to put code and variables for the whole damned world into the form's class, but that does not make it the right thing to do. As we "average users" become practiced professionals, we need to learn how to do things better. If you never even consider using a class to encapsulate the behaviors of a text box, then you are just blindly using 1992 methods of Access programming. It feels that you never even consider whether a class would help to organize and encapsulate the behaviors you are trying to implement. An unbound form is a decidedly complex system. To just blindly stuff crap into the form's module for this form, GUARANTEES that you will be doing the same thing into the next form. An unbound form needs to: 0) Connect to a data source. 1) Load a record from some data source (SQL Server?) 2) Disconnect from the data source. 3) Distribute that data out into controls - text boxes, combo boxes, radio buttons. 4) Watch those controls to discover whether changes are made. 5) connect to a data source. 6) Write the changes back out to SQL Server. 7) HANDLE edit collisions. 8) Disconnect from the data source. The connection to the server can be unavailable when you try to read it. The record being edited can be deleted. What do you do then? The record you are editing can be edited by another user since you read it. How do you discover that? How do you handle that? The record you are editing can be locked when you try and write it back. The connection to the server can be unavailable when you try to write it back. The unholy unbounders make light of bound forms but Access handles ALL OF THIS STUFF for you when you use bound forms. If you are going to do unbound, YOU have to handle all this (and more). I did a 1 year contract at IBM. They were using unbound forms and not handling ANY of this. And the users are SWEARING (in general, but specifically) that they are making changes which just "disappear". Well no shit Sherlock! I can't imagine where the changes went!!!! So when a user says "I want to build an unbound form to edit data", I (personally) am VERY uneasy throwing out a trivial solution. There IS NO TRIVIAL SOLUTION. And none of the solutions I have seen proposed have even discussed ANY of the issues I have mentioned. Back to IBM... the previous programmer wrote the same code, over and over and over and over and over and over and over and over and over and over and over and over and over and over and in each and every form to read the data, distribute the code to the controls, watch the controls for changes, and write the data back out, all without ANY THOUGHT to edit collisions. EVERY FORM had MILES of code in it. Print that puppy out and EVERY FORM had a yard of paper. Can you say "CRAP PROGRAMMING"??? Well, not exactly crap programming, more like novice programming. So now, are you going to encapsulate all of the REQUIRED programming (To do this correctly) in each and every form of YOUR solution? I am not. John W. Colby Reality is what refuses to go away when you do not believe in it On 3/23/2014 9:06 PM, Bill Benson wrote: > So what would the class be, of type Control? And.... why? The method I gave > returns that ANY change occurred, and it is simple. --- This email is free from viruses and malware because avast! Antivirus protection is active. http://www.avast.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