[DUG] Variables stored
Alister Christie
alister at salespartner.co.nz
Fri Jan 21 19:59:54 NZDT 2011
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<jsmith at 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-bounces at delphi.org.nz [mailto:delphi-bounces at 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-bounces at delphi.org.nz [mailto:delphi-bounces at 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-bounces at delphi.org.nz [mailto:delphi-bounces at 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-bounces at delphi.org.nz [mailto:delphi-bounces at 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 at 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 at delphi.org.nz
>> Admin: http://delphi.org.nz/mailman/listinfo/delphi
>> Unsubscribe: send an email to delphi-request at delphi.org.nz with Subject:
>> unsubscribe
>>
>>
>>
>>
>>
>> _______________________________________________
>>
>> NZ Borland Developers Group - Delphi mailing list
>>
>> Post: delphi at delphi.org.nz
>>
>> Admin: http://delphi.org.nz/mailman/listinfo/delphi
>>
>> Unsubscribe: send an email to delphi-request at 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 at delphi.org.nz
>> Admin: http://delphi.org.nz/mailman/listinfo/delphi
>> Unsubscribe: send an email to delphi-request at delphi.org.nz with Subject:
>> unsubscribe
>>
>>
>>
>>
>>
>> _______________________________________________
>>
>> NZ Borland Developers Group - Delphi mailing list
>>
>> Post: delphi at delphi.org.nz
>>
>> Admin: http://delphi.org.nz/mailman/listinfo/delphi
>>
>> Unsubscribe: send an email to delphi-request at delphi.org.nz with Subject:
>> unsubscribe
>>
>> _______________________________________________
>> NZ Borland Developers Group - Delphi mailing list
>> Post: delphi at delphi.org.nz
>> Admin: http://delphi.org.nz/mailman/listinfo/delphi
>> Unsubscribe: send an email to delphi-request at delphi.org.nz with Subject:
>> unsubscribe
>>
> _______________________________________________
> NZ Borland Developers Group - Delphi mailing list
> Post: delphi at delphi.org.nz
> Admin: http://delphi.org.nz/mailman/listinfo/delphi
> Unsubscribe: send an email to delphi-request at delphi.org.nz with Subject: unsubscribe
>
>
More information about the Delphi
mailing list