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
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
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
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
There is another way as well, you can declare simple global variables –
depending where you declare it determines it’s scope - how visible it it is.
In this example string2 can be seen by any unit that uses this one, just as
Form11 (the particular instance of TForm11, and is also a global
Hi John
While all you suggest may be true (I don't know about the compiler
setting stuff) I would strongly recommend anybody starting out with
programming / delphi avoids using global variables. Its a nasty
habit to get into :)
Also the compiler setting
Thanks for all the replies. I'll go through them all and see if I can get my
head around them.
I have to say that after a few months of programming in Dos/DbaseIII/Clipper, I
hardly ever went back to the manuals and wrote a lot of varied and complex
programs. (One being the management an
Assignable typed constants are pointless.
If you are going to declare a constant and then use a compiler switch to
make it behave like a variable, then be honest and just use a variable!!
Typed constants cannot even be used where normal constants can be:
const
ONE: Integer
Hi Wallace
I would recommend getting a book on object oriented design. Here's one
The object primer by Scott Ambler.
Cheers,
Todd.
Thanks for all the replies. I'll go through them all and see if I can
get my head around them.
I have to say that after a few months of programming in
Probably also worth watching some videos
http://delphi.wikia.com/wiki/Delphi_Videos
Check out the 30 Camtasias in 30 days, it's got a bunch of basics in
there which should be helpful
Alister Christie
Computers for People
Ph: 04 471 1849 Fax: 04 471 1266
http://www.salespartner.co.nz
PO Box
I use some global variables. I also have what I assume are other bad habits
like creating plain functions or procedures instead of declaring them inside
the form class. Just lazy.
Ross.
From: delphi-boun...@delphi.org.nz [mailto:delphi-boun...@delphi.org.nz] On
Behalf Of Jolyon Smith
There is nothing wrong with global methods (somehow .NET made then
seem uncool for native languages)
There is nothing wrong with global variables (when used in moderation)
Like Jolyon, I see no reason for assignable typed constants (which I
think were kept for backwards compatibility)
On Fri,
Lazy? or simpler and convenient?
plain functions that might be useful anywhere in any program are best done like
this I would think. Examples are in Delphi units afterall, eg StrUtils
John
I use some global variables. I also have what I assume are other bad habits
like creating plain
Hi
There are some things wrong with global variables and they should be
used where appropriate. I only made a point of saying better to avoid
as they can seem easy for a newbie, who could end up using them for
everything.
Cheers
Rob
On 21/01/2011 3:07 p.m., Jeremy North wrote:
There is
Another issue is you can't use properties as parameters in a function or
procedure so you would need to store the property in a string before calling
a function. What a hassle.
Ross.
From: delphi-boun...@delphi.org.nz [mailto:delphi-boun...@delphi.org.nz] On
Behalf Of Jolyon Smith
Sent:
Yes. But I have done things like this.
procedure DoSomething;
begin
with MainForm do
begin
…
end;
end;
Definitely lazy.
From: delphi-boun...@delphi.org.nz [mailto:delphi-boun...@delphi.org.nz] On
Behalf Of John Bird
Sent: Friday, 21 January 2011 3:17 PM
To: NZ Borland
Yep, you used with...
On Fri, Jan 21, 2011 at 1:32 PM, Ross Levis r...@stationplaylist.com wrote:
Yes. But I have done things like this.
procedure DoSomething;
begin
with MainForm do
begin
…
end;
end;
Definitely lazy.
From: delphi-boun...@delphi.org.nz
It doesn’t take “with” to break the Delphi refactorings. Perfectly ordinary,
healthy, unexceptional, uncomplex code can do that !! I find the refactorings
to be next to useless as a result – when they work at all they simply cannot be
relied on to have worked completely correctly.
The one
I ONLY use it with record structures. It is a real pain in the arse when
visually debuging code and totally unnecessary.
Todd.
There are very, very, VERY (one more time: */VERY/*) few occasions
when *with* should be used, but one that I see no problem with [sic] is:
with SomeComboBox do
I don't use the with clause that often but I do use it in class
methods to instantiate dialog boxes.
eg.
class function TMyDialog.Execute: Boolean;
begin
with Self.Create(nil) do
try
Result := ShowModal = mrOk;
finally
Release;
end;
end;
Cheers,
Colin
On 21 January 2011 14:44,
The Warehouse.
At least still actively doing it now. All for business applications. May
even getting new one. Don't know how many more years to go though.
Edward
_
From: delphi-boun...@delphi.org.nz [mailto:delphi-boun...@delphi.org.nz] On
Behalf Of Leigh Wanstead
Sent: Wednesday,
you might be able to go even one better by setting the Action = caFree
in OnClose and just use
result := Self.Create(nil).ShowModal = mrOK;
removing the with, and cutting the code from 6 lines to 1.
Actually is Self.Create safe - rather than TMyDialog.Create?
Alister Christie
Computers for
you might be able to go even one better by setting the Action = caFree
This is hardly ever a good idea when a form is intended to be used as a
dialog as it is a frequent pattern to pass information back from the dialog
to the invoking code via public properties of the dialog form class:
Dlg
23 matches
Mail list logo
