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