[AccessD] Basic Unbound Form with Classes and Collections Par t 1.

DWUTKA at marlow.com DWUTKA at marlow.com
Mon Jun 12 10:37:01 CDT 2006



It all depends on what you are developing.  In this sample, to really make
it capable, you would want an 'IsDirty' property, which would require all
the applicable fields to have Get/Let statements (so the let statements
could trigger the IsDirty property).  For this demo, however, I wanted to
keep it simple.

However, I do a lot of web stuff, where I have a similar setup that I am
using in a demo.  With a web interface, IsDirty is relatively useless.  You
don't have a truly 'bound' state, so it's either saved or not.

But you do agree that using Public in a class is essentially a property,
it's just not controlled the same.  I haven't gone into Implements, which
would require everything to be get/let/set.

Drew

-----Original Message-----
From: Heenan, Lambert [mailto:Lambert.Heenan at aig.com] 
Sent: Monday, June 12, 2006 8:13 AM
To: 'Access Developers discussion and problem solving'
Subject: Re: [AccessD] Basic Unbound Form with Classes and Collections Par t
1.

Well you don't call a nut and bolt a screw, even though it performs a
similar task. But I appreciate that that is just semantic nit-picking. My
*real* objection is the point about encapsulation. If you are going to use
classes then one of their fundamentally useful features is the ability to
*control* access to their data. This is most commonly done using Get and Set
type properties. Declaring a couple of pubic member fields (or "properties"
if you prefer) defeats that object. 

Lambert

-----Original Message-----
From: accessd-bounces at databaseadvisors.com
[mailto:accessd-bounces at databaseadvisors.com] On Behalf Of DWUTKA at marlow.com
Sent: Friday, June 09, 2006 5:13 PM
To: accessd at databaseadvisors.com
Subject: Re: [AccessD] Basic Unbound Form with Classes and Collections Par t
1.


Why do you say they are not properties?  They show up in intellisense as
properties of the class.  You can set and retrieve their values.

I know what you are saying if you go into the object browser, you won't see
the word property, however, from the code page you can't tell the
difference.

I also COMPLETELY understand the difference between them, but please keep in
mind that this was a BASIC tutorial.  It shows both diversity and is simple
to code.  I completely disagree with you on it defeating the purpose of data
encapsulation.  If a value is not going to have any work done on it at all,
Public MyValue is just as efficient as a property Get and Let statement. (In
fact, I would think it would be faster...but I'm just guessing there).  

Drew

-----Original Message-----
From: Heenan, Lambert [mailto:Lambert.Heenan at aig.com]
Sent: Friday, June 09, 2006 4:01 PM
To: 'Access Developers discussion and problem solving'
Subject: Re: [AccessD] Basic Unbound Form with Classes and Collections Par t
1.



<snip>

Our table has three fields, so we'll create three easy properties, and a
fourth which will be derived.

So, in the code page type the following under the 'Option Compare Database'
line:

Public ID As Long
Public FirstName As String
Public LastName As String

[ These are not properties at all, they are class member fields, and making
them public is a Q&D solution which defeats the purpose of data
encapsulation that classes offer. A real property Get and Set pair would
correct this, with the member fields being change to Private]

Lambert
-- 
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



More information about the AccessD mailing list