Re: [DUG] Variables stored
Actually is Self.Create safe - rather than TMyDialog.Create? I think Jolyon explained it better than me but for me, it means that there is less code that needs to be modified/maintained. Self in the class method will refer the class that the method is being called from. In the case that I have group of dialog boxes with the same standard behaviour, I can define a class method Execute in the base class and use the Self identifier without having to define the Execute class method in each and every descendant class. Cheers, Colin ___ 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
Re: [DUG] Variables stored
Alister wrote: 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. Even better, add a CloseAction property to your own TForm descendent and override DoClose to default to that property value thus avoiding even needing an OnClose handler. That's 0 lines of code :-) Although technically property value assignments are just lines of code in another (interpreted) guise. Jolyon is right about not using Free and using Release instead. What Release does is post a Windows message so that the call of Free on the form instance is deferred until the main Wndproc is back processing messages again by which time all event handlers are sure to have completed. Calling Free may 'seem' to work sometimes but a lurking 'use after Free' behaviour is only going to bite you in the ass eventually. And using caFree is quite safe since, despite the name, it actually calls Release (not Free) on the form instance. Cheers, Paul. ___ 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
Re: [DUG] Variables stored
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 you talk about sounds dangerous as someone
who didn't know about it could become highly confused looking at the
code or trying to compile it on a fresh install of Delphi !
Also note I changed the typo spelling of the subject because it was
annoying me :)
Cheers
Rob
On 21/01/2011 9:04 a.m., John Bird wrote:
There is another way as well, you can declare simple
global variables depending where you declare it determines
its 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 variable) is visible.
String3 can be seen by all procedures in this unit, but
not by anywhere else. If you have lots of simple
variables to store and they dont need to be inherited etc
this is the simplest way to do it.
You can take this further:
If I have lots of constants to declare, or variables to
store I create a unit which is code only (no classes) eg
called storeunit and declare all the constants and variables
I want there, any form or unit that wants access to all
these variables just has to add storeunit to its uses
clause. This centralises all such declarations in one
place away from a form and is very tidy. I will often put
simple global functions and procedures in here too, as they
also become globally available, eg various standard ways for
formatting dates and strings. Also this unit can be uses
in different projects as well. For this just go to
File/New/Unit and the IDE gives you a new blank unit
already to add stuff to a simpler unit with no form or
class stuff.
Here string4 string5 integer1 integer2 integer3 can all
be seen from anywhere that uses Storeunit
It depends on whether you like using global variables or
not. Also its a good idea to use a clear naming convention
for such variables.
There are other tricks you can do too - you can alter
compiler settings to allow assignable constants for a
procedure, then any values assigned here will be preserved
between calls to the procedure. But that seems to be
confusing to me, as it really becomes a variable and not a
constant. I saw that used in and example where the program
wanted a counter of the number of times the procedure was
called, and the counter constant in the procedure was
assigned a new value each time the procedure was called, its
quite a tidy way to do that sort of thing. In this case the
scope (visibility) of the variable is totally limited to the
one procedure.
type
TForm11 = class(TForm)
Button1: TButton;
procedure Button1Click(Sender: TObject);
private
{ Private declarations }
public
{ Public declarations }
MyString : string;
end;
var
Form11: TForm11;
string2:
string;
implementation
uses storeunit;
{$R *.dfm}
var
string3: string;
procedure TForm11.Button1Click(Sender: TObject);
begin
MyString := 'Hello, world!';
string2:=Hello
world2;
string5:=Hello
world5;
end;
unit Storeunit;
interface
var
string4:string;
string5:string;
integer1:integer;
integer2:integer;
integer3:integer;
implementation
end.
John
From: Marshland
Engineering
Sent: Thursday, January 20, 2011 3:45 PM
To: delphi@delphi.org.nz
Subject: [DUG] Variabels stored
Re: [DUG] Variables stored
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 = 1;
procedure Foo(aIndex: Integer = ONE); // ERROR: Constant expression
expected
or:
case iValue of
ONE: ; // ERROR: Constant expression expected
end;
Remove the type declaration from the ONE const, and both compile just fine
(note that this is independent of the Assigned Typed Constants compiler
setting).
A typed constant is to all intents and purposes a variable, and might as
well be declared as such (note that you can initialise a unit variable as
part of it's declaration):
var
ONE: Integer = 1;
One final comment - Delphi really has no concept of a global variable.
The highest visibility is unit variable. You still have to explicitly
use a unit to bring it into scope, and if two units declare variables of
the same name normal scoping rules apply but you can explicitly qualify a
reference using the unit name if you need to override the default scope.
Most of the time global/unit variable is close enough that the distinction
doesn't matter, but when it comes to dogma the old rules that global
variables are the spawn of Satan himself needs to be tempered in Delphi
with the fact that they are a bit better behaved than the sort of global
variable that those ritualistic rules were originally devised for.
However, it is still true that the occasions when a unit variable is called
for are relatively few, but they should not be simply outlawed for being
something they are not.
J
From: delphi-boun...@delphi.org.nz [mailto:delphi-boun...@delphi.org.nz] On
Behalf Of Robert martin
Sent: Friday, 21 January 2011 09:18
To: NZ Borland Developers Group - Delphi List
Subject: Re: [DUG] Variables stored
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 you talk about sounds dangerous as someone who
didn't know about it could become highly confused looking at the code or
trying to compile it on a fresh install of Delphi !
Also note I changed the typo spelling of the subject because it was annoying
me :)
Cheers
Rob
On 21/01/2011 9:04 a.m., John Bird wrote:
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 variable)
is visible.
String3 can be seen by all procedures in this unit, but not by anywhere
else.If you have lots of simple variables to store and they don't need
to be inherited etc this is the simplest way to do it.
You can take this further:
If I have lots of constants to declare, or variables to store I create a
unit which is code only (no classes) eg called storeunit and declare all the
constants and variables I want there, any form or unit that wants access to
all these variables just has to add storeunit to its uses clause. This
centralises all such declarations in one place away from a form and is very
tidy. I will often put simple global functions and procedures in here too,
as they also become globally available, eg various standard ways for
formatting dates and strings. Also this unit can be uses in different
projects as well. For this just go to File/New/Unit and the IDE gives
you a new blank unit already to add stuff to - a simpler unit with no form
or class stuff.
Here string4 string5 integer1 integer2 integer3 can all be seen from
anywhere that uses Storeunit
It depends on whether you like using global variables or not. Also its a
good idea to use a clear naming convention for such variables.
There are other tricks you can do too - you can alter compiler settings to
allow assignable constants for a procedure, then any values assigned here
will be preserved between calls to the procedure. But that seems to be
confusing to me, as it really becomes a variable and not a constant. I saw
that used in and example where the program wanted a counter of the number of
times the procedure was called, and the counter constant in the procedure
was assigned a new value each time the procedure was called, its quite a
tidy way to do that sort of thing. In this case the scope (visibility) of
the variable is totally limited to the one procedure.
type
TForm11 = class(TForm)
Button1: TButton;
procedure Button1Click(Sender: TObject);
private
{ Private declarations }
public
{ Public declarations }
MyString : string;
end;
var
Re: [DUG] Variables stored
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 Sent: Friday, 21 January 2011 9:44 AM To: 'NZ Borland Developers Group - Delphi List' Subject: Re: [DUG] Variables stored 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 = 1; procedure Foo(aIndex: Integer = ONE); // ERROR: Constant expression expected or: case iValue of ONE: ; // ERROR: Constant expression expected end; Remove the type declaration from the ONE const, and both compile just fine (note that this is independent of the Assigned Typed Constants compiler setting). A typed constant is to all intents and purposes a variable, and might as well be declared as such (note that you can initialise a unit variable as part of it's declaration): var ONE: Integer = 1; One final comment - Delphi really has no concept of a global variable. The highest visibility is unit variable. You still have to explicitly use a unit to bring it into scope, and if two units declare variables of the same name normal scoping rules apply but you can explicitly qualify a reference using the unit name if you need to override the default scope. Most of the time global/unit variable is close enough that the distinction doesn't matter, but when it comes to dogma the old rules that global variables are the spawn of Satan himself needs to be tempered in Delphi with the fact that they are a bit better behaved than the sort of global variable that those ritualistic rules were originally devised for. However, it is still true that the occasions when a unit variable is called for are relatively few, but they should not be simply outlawed for being something they are not. J From: delphi-boun...@delphi.org.nz [mailto:delphi-boun...@delphi.org.nz] On Behalf Of Robert martin Sent: Friday, 21 January 2011 09:18 To: NZ Borland Developers Group - Delphi List Subject: Re: [DUG] Variables stored 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 you talk about sounds dangerous as someone who didn't know about it could become highly confused looking at the code or trying to compile it on a fresh install of Delphi ! Also note I changed the typo spelling of the subject because it was annoying me :) Cheers Rob On 21/01/2011 9:04 a.m., John Bird wrote: 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 variable) is visible. String3 can be seen by all procedures in this unit, but not by anywhere else.If you have lots of simple variables to store and they don't need to be inherited etc this is the simplest way to do it. You can take this further: If I have lots of constants to declare, or variables to store I create a unit which is code only (no classes) eg called storeunit and declare all the constants and variables I want there, any form or unit that wants access to all these variables just has to add storeunit to its uses clause. This centralises all such declarations in one place away from a form and is very tidy. I will often put simple global functions and procedures in here too, as they also become globally available, eg various standard ways for formatting dates and strings. Also this unit can be uses in different projects as well. For this just go to File/New/Unit and the IDE gives you a new blank unit already to add stuff to - a simpler unit with no form or class stuff. Here string4 string5 integer1 integer2 integer3 can all be seen from anywhere that uses Storeunit It depends on whether you like using global variables or not. Also its a good idea to use a clear naming convention for such variables. There are other tricks you can do too - you can alter compiler settings to allow assignable constants for a procedure, then any values assigned here will be preserved between calls to the procedure. But that seems to be confusing to me, as it really becomes a variable and not a constant. I saw that used in and example where the program wanted a counter of the number of times the procedure was called, and the counter constant in the procedure
Re: [DUG] Variables stored
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, Jan 21, 2011 at 12:36 PM, Ross Levis r...@stationplaylist.com wrote: 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 Sent: Friday, 21 January 2011 9:44 AM To: 'NZ Borland Developers Group - Delphi List' Subject: Re: [DUG] Variables stored 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 = 1; procedure Foo(aIndex: Integer = ONE); // ERROR: Constant expression expected or: case iValue of ONE: ; // ERROR: Constant expression expected end; Remove the type declaration from the ONE const, and both compile just fine (note that this is independent of the Assigned Typed Constants compiler setting). A typed constant is to all intents and purposes a variable, and might as well be declared as such (note that you can initialise a unit variable as part of it’s declaration): var ONE: Integer = 1; One final comment – Delphi really has no concept of a “global” variable. The highest visibility is “unit variable”. You still have to explicitly “use” a unit to bring it into scope, and if two units declare variables of the same name normal scoping rules apply but you can explicitly qualify a reference using the unit name if you need to override the default scope. Most of the time global/unit variable is close enough that the distinction doesn’t matter, but when it comes to dogma the old rules that “global variables are the spawn of Satan himself” needs to be tempered in Delphi with the fact that they are a bit better “behaved” than the sort of global variable that those ritualistic rules were originally devised for. However, it is still true that the occasions when a unit variable is called for are relatively few, but they should not be simply outlawed for being something they are not. J From: delphi-boun...@delphi.org.nz [mailto:delphi-boun...@delphi.org.nz] On Behalf Of Robert martin Sent: Friday, 21 January 2011 09:18 To: NZ Borland Developers Group - Delphi List Subject: Re: [DUG] Variables stored 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 you talk about sounds dangerous as someone who didn't know about it could become highly confused looking at the code or trying to compile it on a fresh install of Delphi ! Also note I changed the typo spelling of the subject because it was annoying me :) Cheers Rob On 21/01/2011 9:04 a.m., John Bird wrote: 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 variable) is visible. String3 can be seen by all procedures in this unit, but not by anywhere else. If you have lots of simple variables to store and they don’t need to be inherited etc this is the simplest way to do it. You can take this further: If I have lots of constants to declare, or variables to store I create a unit which is code only (no classes) eg called storeunit and declare all the constants and variables I want there, any form or unit that wants access to all these variables just has to add storeunit to its uses clause. This centralises all such declarations in one place away from a form and is very tidy. I will often put simple global functions and procedures in here too, as they also become globally available, eg various standard ways for formatting dates and strings. Also this unit can be uses in different projects as well. For this just go to File/New/Unit and the IDE gives you a new blank unit already to add stuff to – a simpler unit with no form or class stuff. Here string4 string5 integer1 integer2 integer3 can all be seen from anywhere that uses Storeunit It depends on whether you like using global variables or not. Also its a good idea to use a clear naming convention for such variables. There are other
Re: [DUG] Variables stored
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 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 Sent: Friday, 21 January 2011 9:44 AM To: 'NZ Borland Developers Group - Delphi List' Subject: Re: [DUG] Variables stored 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 = 1; procedure Foo(aIndex: Integer = ONE); // ERROR: Constant expression expected or: case iValue of ONE: ; // ERROR: Constant expression expected end; Remove the type declaration from the ONE const, and both compile just fine (note that this is independent of the Assigned Typed Constants compiler setting). A typed constant is to all intents and purposes a variable, and might as well be declared as such (note that you can initialise a unit variable as part of it’s declaration): var ONE: Integer = 1; One final comment – Delphi really has no concept of a “global” variable. The highest visibility is “unit variable”. You still have to explicitly “use” a unit to bring it into scope, and if two units declare variables of the same name normal scoping rules apply but you can explicitly qualify a reference using the unit name if you need to override the default scope. Most of the time global/unit variable is close enough that the distinction doesn’t matter, but when it comes to dogma the old rules that “global variables are the spawn of Satan himself” needs to be tempered in Delphi with the fact that they are a bit better “behaved” than the sort of global variable that those ritualistic rules were originally devised for. However, it is still true that the occasions when a unit variable is called for are relatively few, but they should not be simply outlawed for being something they are not. J From: delphi-boun...@delphi.org.nz [mailto:delphi-boun...@delphi.org.nz] On Behalf Of Robert martin Sent: Friday, 21 January 2011 09:18 To: NZ Borland Developers Group - Delphi List Subject: Re: [DUG] Variables stored 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 you talk about sounds dangerous as someone who didn't know about it could become highly confused looking at the code or trying to compile it on a fresh install of Delphi ! Also note I changed the typo spelling of the subject because it was annoying me :) Cheers Rob On 21/01/2011 9:04 a.m., John Bird wrote: 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 variable) is visible. String3 can be seen by all procedures in this unit, but not by anywhere else. If you have lots of simple variables to store and they don’t need to be inherited etc this is the simplest way to do it. You can take this further: If I have lots of constants to declare, or variables to store I create a unit which is code only (no classes) eg called storeunit and declare all the constants and variables I want there, any form or unit that wants access to all these variables just has to add storeunit to its uses clause. This centralises all such declarations in one place away from a form and is very tidy. I will often put simple global functions and procedures in here too, as they also become globally available, eg various standard ways for formatting dates and strings. Also this unit can be uses in different projects as well. For this just go to File/New/Unit and the IDE gives you a new blank unit already to add stuff to – a simpler unit with no form or class stuff. Here string4 string5 integer1 integer2 integer3 can all be seen from anywhere that uses Storeunit It depends on whether you like using global variables or not. Also its a good idea to use a clear naming convention for such variables. There are other tricks you can do too - you can alter compiler settings to allow assignable constants for a procedure, then any values assigned here will be preserved between calls to the procedure
Re: [DUG] Variables stored
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 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, Jan 21, 2011 at 12:36 PM, Ross Levisr...@stationplaylist.com wrote: 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 Sent: Friday, 21 January 2011 9:44 AM To: 'NZ Borland Developers Group - Delphi List' Subject: Re: [DUG] Variables stored 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 = 1; procedure Foo(aIndex: Integer = ONE); // ERROR: Constant expression expected or: case iValue of ONE: ; // ERROR: Constant expression expected end; Remove the type declaration from the ONE const, and both compile just fine (note that this is independent of the Assigned Typed Constants compiler setting). A typed constant is to all intents and purposes a variable, and might as well be declared as such (note that you can initialise a unit variable as part of it’s declaration): var ONE: Integer = 1; One final comment – Delphi really has no concept of a “global” variable. The highest visibility is “unit variable”. You still have to explicitly “use” a unit to bring it into scope, and if two units declare variables of the same name normal scoping rules apply but you can explicitly qualify a reference using the unit name if you need to override the default scope. Most of the time global/unit variable is close enough that the distinction doesn’t matter, but when it comes to dogma the old rules that “global variables are the spawn of Satan himself” needs to be tempered in Delphi with the fact that they are a bit better “behaved” than the sort of global variable that those ritualistic rules were originally devised for. However, it is still true that the occasions when a unit variable is called for are relatively few, but they should not be simply outlawed for being something they are not. J From: delphi-boun...@delphi.org.nz [mailto:delphi-boun...@delphi.org.nz] On Behalf Of Robert martin Sent: Friday, 21 January 2011 09:18 To: NZ Borland Developers Group - Delphi List Subject: Re: [DUG] Variables stored 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 you talk about sounds dangerous as someone who didn't know about it could become highly confused looking at the code or trying to compile it on a fresh install of Delphi ! Also note I changed the typo spelling of the subject because it was annoying me :) Cheers Rob On 21/01/2011 9:04 a.m., John Bird wrote: 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 variable) is visible. String3 can be seen by all procedures in this unit, but not by anywhere else.If you have lots of simple variables to store and they don’t need to be inherited etc this is the simplest way to do it. You can take this further: If I have lots of constants to declare, or variables to store I create a unit which is code only (no classes) eg called storeunit and declare all the constants and variables I want there, any form or unit that wants access to all these variables just has to add storeunit to its uses clause. This centralises all such declarations in one place away from a form and is very tidy. I will often put simple global functions and procedures in here too, as they also become globally available, eg various standard ways for formatting dates and strings. Also this unit can be uses in different projects as well. For this just go to File/New/Unit and the IDE gives you a new blank unit already to add stuff to – a simpler unit
Re: [DUG] Variables stored
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 Developers Group - Delphi List Subject: Re: [DUG] Variables stored 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 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 Sent: Friday, 21 January 2011 9:44 AM To: 'NZ Borland Developers Group - Delphi List' Subject: Re: [DUG] Variables stored 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 = 1; procedure Foo(aIndex: Integer = ONE); // ERROR: Constant expression expected or: case iValue of ONE: ; // ERROR: Constant expression expected end; Remove the type declaration from the ONE const, and both compile just fine (note that this is independent of the Assigned Typed Constants compiler setting). A typed constant is to all intents and purposes a variable, and might as well be declared as such (note that you can initialise a unit variable as part of it’s declaration): var ONE: Integer = 1; One final comment – Delphi really has no concept of a “global” variable. The highest visibility is “unit variable”. You still have to explicitly “use” a unit to bring it into scope, and if two units declare variables of the same name normal scoping rules apply but you can explicitly qualify a reference using the unit name if you need to override the default scope. Most of the time global/unit variable is close enough that the distinction doesn’t matter, but when it comes to dogma the old rules that “global variables are the spawn of Satan himself” needs to be tempered in Delphi with the fact that they are a bit better “behaved” than the sort of global variable that those ritualistic rules were originally devised for. However, it is still true that the occasions when a unit variable is called for are relatively few, but they should not be simply outlawed for being something they are not. J From: delphi-boun...@delphi.org.nz [mailto:delphi-boun...@delphi.org.nz] On Behalf Of Robert martin Sent: Friday, 21 January 2011 09:18 To: NZ Borland Developers Group - Delphi List Subject: Re: [DUG] Variables stored 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 you talk about sounds dangerous as someone who didn't know about it could become highly confused looking at the code or trying to compile it on a fresh install of Delphi ! Also note I changed the typo spelling of the subject because it was annoying me :) Cheers Rob On 21/01/2011 9:04 a.m., John Bird wrote: 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 variable) is visible. String3 can be seen by all procedures in this unit, but not by anywhere else. If you have lots of simple variables to store and they don’t need to be inherited etc this is the simplest way to do it. You can take this further: If I have lots of constants to declare, or variables to store I create a unit which is code only (no classes) eg called storeunit and declare all the constants and variables I want there, any form or unit that wants access to all these variables just has to add storeunit to its uses clause. This centralises all such declarations in one place away from a form and is very tidy. I will often put simple global functions and procedures in here too, as they also become globally available, eg various standard ways for formatting dates and strings. Also this unit can be uses in different projects as well. For this just go to File/New/Unit and the IDE gives you a new blank unit already to add stuff to – a simpler unit with no form or class stuff. Here string4 string5 integer1 integer2 integer3 can all be seen from
Re: [DUG] Variables stored
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 [mailto:delphi-boun...@delphi.org.nz] On Behalf Of John Bird Sent: Friday, 21 January 2011 3:17 PM To: NZ Borland Developers Group - Delphi List Subject: Re: [DUG] Variables stored 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 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 Sent: Friday, 21 January 2011 9:44 AM To: 'NZ Borland Developers Group - Delphi List' Subject: Re: [DUG] Variables stored 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 = 1; procedure Foo(aIndex: Integer = ONE); // ERROR: Constant expression expected or: case iValue of ONE: ; // ERROR: Constant expression expected end; Remove the type declaration from the ONE const, and both compile just fine (note that this is independent of the Assigned Typed Constants compiler setting). A typed constant is to all intents and purposes a variable, and might as well be declared as such (note that you can initialise a unit variable as part of it’s declaration): var ONE: Integer = 1; One final comment – Delphi really has no concept of a “global” variable. The highest visibility is “unit variable”. You still have to explicitly “use” a unit to bring it into scope, and if two units declare variables of the same name normal scoping rules apply but you can explicitly qualify a reference using the unit name if you need to override the default scope. Most of the time global/unit variable is close enough that the distinction doesn’t matter, but when it comes to dogma the old rules that “global variables are the spawn of Satan himself” needs to be tempered in Delphi with the fact that they are a bit better “behaved” than the sort of global variable that those ritualistic rules were originally devised for. However, it is still true that the occasions when a unit variable is called for are relatively few, but they should not be simply outlawed for being something they are not. J From: delphi-boun...@delphi.org.nz [mailto:delphi-boun...@delphi.org.nz] On Behalf Of Robert martin Sent: Friday, 21 January 2011 09:18 To: NZ Borland Developers Group - Delphi List Subject: Re: [DUG] Variables stored 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 you talk about sounds dangerous as someone who didn't know about it could become highly confused looking at the code or trying to compile it on a fresh install of Delphi ! Also note I changed the typo spelling of the subject because it was annoying me :) Cheers Rob On 21/01/2011 9:04 a.m., John Bird wrote: 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 variable) is visible. String3 can be seen by all procedures in this unit, but not by anywhere else. If you have lots of simple variables to store and they don’t need to be inherited etc this is the simplest way to do it. You can take this further: If I have lots of constants to declare, or variables to store I create a unit which is code only (no classes) eg called storeunit and declare all the constants and variables I want there, any form or unit that wants access to all these variables just has to add storeunit to its uses clause. This centralises all such declarations in one place away from a form and is very tidy. I will often put simple global functions and procedures in here too, as they also become globally available, eg various standard ways for formatting dates and strings. Also this unit can be uses in different projects as well. For this just go to File/New/Unit and the IDE gives you a new blank unit already to add stuff
Re: [DUG] Variables stored
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 thing “with” does do is “break” the debugger, but even that isn’t accurate. It is more accurate to say that “with” reveals a bug in the debugger (scope resolution that does not match that applied by the compiler) that should be fixed. 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 ItemIndex := Items.IndexOf( someStringValue ); (or at least I do when working with combobox/list classes that don’t provide a more convenient way of selecting an item by value, rather than index) J From: delphi-boun...@delphi.org.nz [mailto:delphi-boun...@delphi.org.nz] On Behalf Of Alister Christie Sent: Friday, 21 January 2011 16:11 To: NZ Borland Developers Group - Delphi List Subject: Re: [DUG] Variables stored With is pretty dangerous because of scoping issues - and it breaks all the refactorings. I'd like to see a with f : MyDataModule.MyDataSet do or similar construct. I believe there is something like this in Prism. Alister Christie Computers for People Ph: 04 471 1849 Fax: 04 471 1266 http://www.salespartner.co.nz PO Box 13085 Johnsonville Wellington On 21/01/2011 3:32 p.m., Ross Levis 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 [mailto:delphi-boun...@delphi.org.nz] On Behalf Of John Bird Sent: Friday, 21 January 2011 3:17 PM To: NZ Borland Developers Group - Delphi List Subject: Re: [DUG] Variables stored 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 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 Sent: Friday, 21 January 2011 9:44 AM To: 'NZ Borland Developers Group - Delphi List' Subject: Re: [DUG] Variables stored 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 = 1; procedure Foo(aIndex: Integer = ONE); // ERROR: Constant expression expected or: case iValue of ONE: ; // ERROR: Constant expression expected end; Remove the type declaration from the ONE const, and both compile just fine (note that this is independent of the Assigned Typed Constants compiler setting). A typed constant is to all intents and purposes a variable, and might as well be declared as such (note that you can initialise a unit variable as part of it’s declaration): var ONE: Integer = 1; One final comment – Delphi really has no concept of a “global” variable. The highest visibility is “unit variable”. You still have to explicitly “use” a unit to bring it into scope, and if two units declare variables of the same name normal scoping rules apply but you can explicitly qualify a reference using the unit name if you need to override the default scope. Most of the time global/unit variable is close enough that the distinction doesn’t matter, but when it comes to dogma the old rules that “global variables are the spawn of Satan himself” needs to be tempered in Delphi with the fact that they are a bit better “behaved” than the sort of global variable that those ritualistic rules were originally devised for. However, it is still true that the occasions when a unit variable is called for are relatively few, but they should not be simply outlawed for being something they are not. J From: delphi-boun...@delphi.org.nz [mailto:delphi-boun...@delphi.org.nz] On Behalf Of Robert martin Sent: Friday, 21 January 2011 09:18 To: NZ Borland Developers Group - Delphi List Subject: Re: [DUG] Variables stored 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 you talk about sounds dangerous as someone who didn't know about it could become highly confused looking at the code or trying to compile it on a fresh
Re: [DUG] Variables stored
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 ItemIndex := Items.IndexOf( someStringValue ); (or at least I do when working with combobox/list classes that don’t provide a more convenient way of selecting an item by value, rather than index) J *From:* delphi-boun...@delphi.org.nz [mailto:delphi-boun...@delphi.org.nz] *On Behalf Of *Alister Christie *Sent:* Friday, 21 January 2011 16:11 *To:* NZ Borland Developers Group - Delphi List *Subject:* Re: [DUG] Variables stored With is pretty dangerous because of scoping issues - and it breaks all the refactorings. I'd like to see a with f : MyDataModule.MyDataSet do or similar construct. I believe there is something like this in Prism. Alister Christie Computers for People Ph: 04 471 1849 Fax: 04 471 1266 http://www.salespartner.co.nz PO Box 13085 Johnsonville Wellington On 21/01/2011 3:32 p.m., Ross Levis 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 mailto: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 Developers Group - Delphi List *Subject:* Re: [DUG] Variables stored 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 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 [mailto:delphi-boun...@delphi.org.nz] *On Behalf Of *Jolyon Smith *Sent:* Friday, 21 January 2011 9:44 AM *To:* 'NZ Borland Developers Group - Delphi List' *Subject:* Re: [DUG] Variables stored 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 = 1; procedure Foo(aIndex: Integer = ONE); // ERROR: Constant expression expected or: case iValue of ONE: ; // ERROR: Constant expression expected end; Remove the type declaration from the ONE const, and both compile just fine (note that this is independent of the Assigned Typed Constants compiler setting). A typed constant is to all intents and purposes a variable, and might as well be declared as such (note that you can initialise a unit variable as part of it’s declaration): var ONE: Integer = 1; One final comment – Delphi really has no concept of a “global” variable. The highest visibility is “unit variable”. You still have to explicitly “use” a unit to bring it into scope, and if two units declare variables of the same name normal scoping rules apply but you can explicitly qualify a reference using the unit name if you need to override the default scope. Most of the time global/unit variable is close enough that the distinction doesn’t matter, but when it comes to dogma the old rules that “global variables are the spawn of Satan himself” needs to be tempered in Delphi with the fact that they are a bit better “behaved” than the sort of global variable that those ritualistic rules were originally devised for. However, it is still true that the occasions when a unit variable is called for are relatively few, but they should not be simply outlawed for being something they are not. J *From:* delphi-boun...@delphi.org.nz mailto:delphi-boun...@delphi.org.nz [mailto:delphi-boun...@delphi.org.nz] *On Behalf Of *Robert martin *Sent:* Friday, 21 January 2011 09:18 *To:* NZ Borland Developers Group - Delphi List *Subject:* Re: [DUG] Variables stored 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 you talk about sounds dangerous as someone who didn't know about it could become highly confused looking at the code or trying to compile it on a fresh install of Delphi ! Also note I changed the typo spelling of the subject because it was annoying me :) Cheers Rob On 21/01/2011 9:04 a.m., John Bird wrote: 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
Re: [DUG] Variables stored
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, Jolyon Smith jsm...@deltics.co.nz wrote: 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 thing “with” does do is “break” the debugger, but even that isn’t accurate. It is more accurate to say that “with” reveals a bug in the debugger (scope resolution that does not match that applied by the compiler) that should be fixed. 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 ItemIndex := Items.IndexOf( someStringValue ); (or at least I do when working with combobox/list classes that don’t provide a more convenient way of selecting an item by value, rather than index) J From: delphi-boun...@delphi.org.nz [mailto:delphi-boun...@delphi.org.nz] On Behalf Of Alister Christie Sent: Friday, 21 January 2011 16:11 To: NZ Borland Developers Group - Delphi List Subject: Re: [DUG] Variables stored With is pretty dangerous because of scoping issues - and it breaks all the refactorings. I'd like to see a with f : MyDataModule.MyDataSet do or similar construct. I believe there is something like this in Prism. Alister Christie Computers for People Ph: 04 471 1849 Fax: 04 471 1266 http://www.salespartner.co.nz PO Box 13085 Johnsonville Wellington On 21/01/2011 3:32 p.m., Ross Levis 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 [mailto:delphi-boun...@delphi.org.nz] On Behalf Of John Bird Sent: Friday, 21 January 2011 3:17 PM To: NZ Borland Developers Group - Delphi List Subject: Re: [DUG] Variables stored 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 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 Sent: Friday, 21 January 2011 9:44 AM To: 'NZ Borland Developers Group - Delphi List' Subject: Re: [DUG] Variables stored 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 = 1; procedure Foo(aIndex: Integer = ONE); // ERROR: Constant expression expected or: case iValue of ONE: ; // ERROR: Constant expression expected end; Remove the type declaration from the ONE const, and both compile just fine (note that this is independent of the Assigned Typed Constants compiler setting). A typed constant is to all intents and purposes a variable, and might as well be declared as such (note that you can initialise a unit variable as part of it’s declaration): var ONE: Integer = 1; One final comment – Delphi really has no concept of a “global” variable. The highest visibility is “unit variable”. You still have to explicitly “use” a unit to bring it into scope, and if two units declare variables of the same name normal scoping rules apply but you can explicitly qualify a reference using the unit name if you need to override the default scope. Most of the time global/unit variable is close enough that the distinction doesn’t matter, but when it comes to dogma the old rules that “global variables are the spawn of Satan himself” needs to be tempered in Delphi with the fact that they are a bit better “behaved” than the sort of global variable that those ritualistic rules were originally devised for. However, it is still true that the occasions when a unit variable is called for are relatively few, but they should not be simply outlawed for being something they are not. J From: delphi-boun...@delphi.org.nz [mailto:delphi-boun...@delphi.org.nz] On Behalf Of Robert martin Sent: Friday, 21 January 2011 09:18 To: NZ Borland Developers Group - Delphi List Subject: Re: [DUG] Variables stored Hi John While all you suggest may be true (I
Re: [DUG] Variables stored
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 People Ph: 04 471 1849 Fax: 04 471 1266 http://www.salespartner.co.nz PO Box 13085 Johnsonville Wellington On 21/01/2011 5:00 p.m., Colin Johnsun wrote: 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, Jolyon Smithjsm...@deltics.co.nz wrote: 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 thing “with” does do is “break” the debugger, but even that isn’t accurate. It is more accurate to say that “with” reveals a bug in the debugger (scope resolution that does not match that applied by the compiler) that should be fixed. 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 ItemIndex := Items.IndexOf( someStringValue ); (or at least I do when working with combobox/list classes that don’t provide a more convenient way of selecting an item by value, rather than index) J From: delphi-boun...@delphi.org.nz [mailto:delphi-boun...@delphi.org.nz] On Behalf Of Alister Christie Sent: Friday, 21 January 2011 16:11 To: NZ Borland Developers Group - Delphi List Subject: Re: [DUG] Variables stored With is pretty dangerous because of scoping issues - and it breaks all the refactorings. I'd like to see a with f : MyDataModule.MyDataSet do or similar construct. I believe there is something like this in Prism. Alister Christie Computers for People Ph: 04 471 1849 Fax: 04 471 1266 http://www.salespartner.co.nz PO Box 13085 Johnsonville Wellington On 21/01/2011 3:32 p.m., Ross Levis 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 [mailto:delphi-boun...@delphi.org.nz] On Behalf Of John Bird Sent: Friday, 21 January 2011 3:17 PM To: NZ Borland Developers Group - Delphi List Subject: Re: [DUG] Variables stored 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 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 Sent: Friday, 21 January 2011 9:44 AM To: 'NZ Borland Developers Group - Delphi List' Subject: Re: [DUG] Variables stored 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 = 1; procedure Foo(aIndex: Integer = ONE); // ERROR: Constant expression expected or: case iValue of ONE: ; // ERROR: Constant expression expected end; Remove the type declaration from the ONE const, and both compile just fine (note that this is independent of the Assigned Typed Constants compiler setting). A typed constant is to all intents and purposes a variable, and might as well be declared as such (note that you can initialise a unit variable as part of it’s declaration): var ONE: Integer = 1; One final comment – Delphi really has no concept of a “global” variable. The highest visibility is “unit variable”. You still have to explicitly “use” a unit to bring it into scope, and if two units declare variables of the same name normal scoping rules apply but you can explicitly qualify a reference using the unit name if you need to override the default scope. Most of the time global/unit variable is close enough that the distinction doesn’t matter, but when it comes to dogma the old rules that “global variables are the spawn of Satan himself” needs to be tempered in Delphi with the fact that they are a bit better “behaved” than the sort of global variable that those ritualistic rules were
Re: [DUG] Variables stored
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 := TSomeDialog.Create(NIL); Try If dlg.ShowMOdal = mrOK then Begin FileName := dlg.FileName; // blah blah End; Finally Dlg.Free; End; Note the use of Free in this context is safe. Release is advised if you Free a form in response to some event on the form itself, e.g. in an OnClick of a button. This avoids the form being destroyed out from underneath the feet of the code in the event handler. But when you have invoked a form using ShowModal, ShowModal will not return until the message loop created for the form has terminated. If the form could be freed from out underneath the feet of this code then you are in serious trouble. In general, it is a bad idea to have a situation that could result in a form being free'd in response to an event on that form. When I see Release() being used I am immediately nervous. Actually is Self.Create safe - rather than TMyDialog.Create? Much safer imho. 1) if you renamed your class your method body doesn't need to change. Yeah you can use a refactoring which will take care of such details, but why rely on tool support *more* than you strictly need to ? (and see previous comments about dubious reliability of ref[a/u]ctorings) 2) if you user poor man's code re-use and copy/pasted this method (perhaps you have another form where you want a class Execute() method, then if you have hard-wired the class name in the method body, and if you forget to fix it in your pasted code (happens ALL too often!) then your second dialog class is going to instantiate the wrong form class, which could have you banging your head for a while until you realise your mistake. 3) The self is itself I think redundant. ___ 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
