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