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
