[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