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 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 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 >> >> >> >> 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 > > > ----- > 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
