[AccessD] Unbound Form Check For Changes

Whatever.  I want to  help them see (and do) the whole job.

Carry on, I'll stay out of it.

John W. Colby

Reality is what refuses to go away
when you do not believe in it

On 3/23/2014 10:12 PM, Bill Benson wrote:
> No argument.
>
> I was trying to get the user over a small hump:
>
> http://goo.gl/y1jb6P
>
>
> You want to help them build:
>
> http://goo.gl/yrudv9
>
>
> Oh well, once a rocket scientist, always a rocket scientist.
>
> -----Original Message-----
> From: accessd-bounces at databaseadvisors.com
> [mailto:accessd-bounces at databaseadvisors.com] On Behalf Of John W Colby
> Sent: Sunday, March 23, 2014 9:55 PM
> To: Access Developers discussion and problem solving
> 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
>


---
This email is free from viruses and malware because avast! Antivirus protection is active.
http://www.avast.com