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:* [email protected]
[mailto:[email protected]] *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:* [email protected]
<mailto:[email protected]>
[mailto:[email protected]] *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:* [email protected]
<mailto:[email protected]>
[mailto:[email protected]] *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:* [email protected]
<mailto:[email protected]>
[mailto:[email protected]] *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 Engineering <mailto:[email protected]>
*Sent:* Thursday, January 20, 2011 3:45 PM
*To:* [email protected] <mailto:[email protected]>
*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: [email protected] <mailto:[email protected]>
Admin: http://delphi.org.nz/mailman/listinfo/delphi
Unsubscribe: send an email to [email protected]
<mailto:[email protected]> with Subject: unsubscribe
_______________________________________________
NZ Borland Developers Group - Delphi mailing list
Post:[email protected] <mailto:[email protected]>
Admin:http://delphi.org.nz/mailman/listinfo/delphi
Unsubscribe: send an email [email protected]
<mailto:[email protected]> with Subject: unsubscribe
No virus found in this message.
Checked by AVG - www.avg.com <http://www.avg.com>
Version: 10.0.1191 / Virus Database: 1435/3392 - Release Date: 01/20/11
------------------------------------------------------------------------
_______________________________________________
NZ Borland Developers Group - Delphi mailing list
Post: [email protected] <mailto:[email protected]>
Admin: http://delphi.org.nz/mailman/listinfo/delphi
Unsubscribe: send an email to [email protected]
<mailto:[email protected]> with Subject: unsubscribe
_______________________________________________
NZ Borland Developers Group - Delphi mailing list
Post:[email protected] <mailto:[email protected]>
Admin:http://delphi.org.nz/mailman/listinfo/delphi
Unsubscribe: send an email [email protected]
<mailto:[email protected]> with Subject: unsubscribe
_______________________________________________
NZ Borland Developers Group - Delphi mailing list
Post: [email protected]
Admin: http://delphi.org.nz/mailman/listinfo/delphi
Unsubscribe: send an email to [email protected] with Subject:
unsubscribe
_______________________________________________
NZ Borland Developers Group - Delphi mailing list
Post: [email protected]
Admin: http://delphi.org.nz/mailman/listinfo/delphi
Unsubscribe: send an email to [email protected] with Subject:
unsubscribe
