[DUG] Variabels stored

[Jolyon Smith]

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-bounces at delphi.org.nz [mailto:delphi-bounces at 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-bounces at delphi.org.nz [mailto:delphi-bounces at 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-bounces at delphi.org.nz [mailto:delphi-bounces at delphi.org.nz] On
Behalf Of Marshland Engineering
Sent: Thursday, 20 January 2011 3:45 p.m.
To: delphi at 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 at delphi.org.nz  
Admin: http://delphi.org.nz/mailman/listinfo/delphi  
Unsubscribe: send an email to delphi-request at delphi.org.nz with Subject:
unsubscribe  

  

 
 
_______________________________________________
NZ Borland Developers Group - Delphi mailing list
Post: delphi at delphi.org.nz
Admin: http://delphi.org.nz/mailman/listinfo/delphi
Unsubscribe: send an email to delphi-request at delphi.org.nz with Subject:
unsubscribe

 

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://listserver.123.net.nz/pipermail/delphi/attachments/20110121/3613f6e9/attachment-0001.html