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 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 <mailto:marshl...@marshland.co.nz> Engineering
Sent: Thursday, January 20, 2011 3:45 PM
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
No virus found in this message.
Checked by AVG - www.avg.com
Version: 10.0.1191 / Virus Database: 1435/3392 - Release Date: 01/20/11
_____
_______________________________________________
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
