[DUG] Variables stored

Todd todd.martin.nz at gmail.com
Fri Jan 21 16:56:27 NZDT 2011


I ONLY use it with record structures. It is a real pain in the arse when 
visually debuging code and totally unnecessary.

Todd.
>
> 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> 
> [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> 
> [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> 
> [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 <mailto:marshland at marshland.co.nz>
>
> *Sent:* Thursday, January 20, 2011 3:45 PM
>
> *To:* delphi at delphi.org.nz <mailto: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 <mailto:delphi at delphi.org.nz>
> Admin: http://delphi.org.nz/mailman/listinfo/delphi
> Unsubscribe: send an email to delphi-request at delphi.org.nz 
> <mailto:delphi-request at delphi.org.nz> with Subject: unsubscribe
>
>   
>   
> _______________________________________________
> NZ Borland Developers Group - Delphi mailing list
> Post:delphi at delphi.org.nz  <mailto:delphi at delphi.org.nz>
> Admin:http://delphi.org.nz/mailman/listinfo/delphi
> Unsubscribe: send an email todelphi-request at delphi.org.nz  <mailto:delphi-request at delphi.org.nz>  with Subject: unsubscribe
>
> No virus found in this message.
> Checked by AVG - www.avg.com <http://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 <mailto:delphi at delphi.org.nz>
> Admin: http://delphi.org.nz/mailman/listinfo/delphi
> Unsubscribe: send an email to delphi-request at delphi.org.nz 
> <mailto:delphi-request at delphi.org.nz> with Subject: unsubscribe
>
>   
>   
> _______________________________________________
> NZ Borland Developers Group - Delphi mailing list
> Post:delphi at delphi.org.nz  <mailto:delphi at delphi.org.nz>
> Admin:http://delphi.org.nz/mailman/listinfo/delphi
> Unsubscribe: send an email todelphi-request at delphi.org.nz  <mailto: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

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://listserver.123.net.nz/pipermail/delphi/attachments/20110121/08637f51/attachment-0001.html 


More information about the Delphi mailing list