Well, to be fair the same is true even if you declare it simply as a public
member. You change that public member to a public property with read/write
accessors if you need to, without changing the code that uses the public
member.
The reason to declare a member as a property is when you positively wish to
hide the implementation, not because you may wish to in the future.
Note also that for record types, exposure as a property makes such members
harder and unintuitive to work with:
TShape = class
Private
fRect: TRect;
public
property Rect: TRect read fRect write fRect;
end;
shape.Rect.Left := 100; // Error: Left-side cannot be assigned to
you have to instead write:
newRect := shape.Rect;
newRect.Left := 100;
shape.Rect := newRect;
or
shape.Rect := Rect(100, shape.Rect.Top, shape.Rect.Right,
shape.Rect.bottom);
or get real nasty and expose the property by reference:
property Rect: PRect read get_Rect; //get_Rect returns the PRect of
@fRect
allowing you to write:
shape.Rect.Left := 100; // Now this is fine
But notice now that we have a read/write "property" that is declared as
read-only and TShape is oblivious to any changes made to its fRect.
Or you could expose each field of the record via a separate property (not a
bad idea for a TRect, but for more complex/larger records this could be
cumbersome).
This area is a bit sticky, to say the least, and I don't think there's one
single "right" approach - it depends very much on the specific case at hand.
Having said AAALLL that, I have long since got in the habit of never
exposing public member variables in a class. J
From: delphi-boun...@delphi.org.nz [mailto:delphi-boun...@delphi.org.nz] On
Behalf Of David Moorhouse (DUG)
Sent: Friday, 21 January 2011 07:33
To: NZ Borland Developers Group - Delphi List
Subject: Re: [DUG] Variabels stored
Because a property hides the implementation details ... you can change to
read / write methods later with no change to the code that is using the
property. A public field exposes the implementation.
Cheers
D
On 21/01/11 00:44, Ross Levis wrote:
I don't see the point in doing that, unless the read/write are functions or
procedures. Just make the string public.
From: delphi-boun...@delphi.org.nz [mailto:delphi-boun...@delphi.org.nz] On
Behalf Of David Moorhouse (DUG)
Sent: Thursday, 20 January 2011 11:18 PM
To: NZ Borland Developers Group - Delphi List
Subject: Re: [DUG] Variabels stored
Or as field properties if you want to access them from another form ...
type
TWallaceForm = class(TForm)
btnOK: TButton;
private
FWallacesPrivateVar: string; // private storage
public
property WallacesPrivateVar: string read FWallacesPrivateVar write
FWallacesPrivateVar;
...
end;
Cheers
D
On 20/01/11 16:09, Conor Boyd wrote:
Probably as a field on the form class that you're dealing with.
e.g.
type
TWallaceForm = class(TForm)
btnOK: TButton;
...
txtWallacesHiddenTextBox: TEdit;
...
private
FWallacesPrivateVar: string; // use this instead of your hidden
text box.
// Can create as many
"variables" (or fields as they're known in Delphi parlance, hence the F
prefix)
// of as many different
types as you like.
...
end;
Hope I've understood what you're asking for correctly.
HTH,
Conor
From: delphi-boun...@delphi.org.nz [mailto:delphi-boun...@delphi.org.nz] On
Behalf Of Marshland Engineering
Sent: Thursday, 20 January 2011 3:45 p.m.
To: delphi@delphi.org.nz
Subject: [DUG] Variabels stored
Is there a way to store variables so I can use them from one procedure to
another?
I have been currently storing them in hidden edit.text boxes on the form but
there must be a better way.
Cheers Wallace
_______________________________________________
NZ Borland Developers Group - Delphi mailing list
Post: delphi@delphi.org.nz
Admin: http://delphi.org.nz/mailman/listinfo/delphi
Unsubscribe: send an email to delphi-requ...@delphi.org.nz with Subject:
unsubscribe
_______________________________________________
NZ Borland Developers Group - Delphi mailing list
Post: delphi@delphi.org.nz
Admin: http://delphi.org.nz/mailman/listinfo/delphi
Unsubscribe: send an email to delphi-requ...@delphi.org.nz with Subject:
unsubscribe
_______________________________________________
NZ Borland Developers Group - Delphi mailing list
Post: delphi@delphi.org.nz
Admin: http://delphi.org.nz/mailman/listinfo/delphi
Unsubscribe: send an email to delphi-requ...@delphi.org.nz with Subject:
unsubscribe
