Re: newbies: beware script locals
On Friday, Feb 28, 2003, at 04:01 Australia/Sydney, Ben Rubinstein <[EMAIL PROTECTED]> wrote: > on 2/27/03 10:44 AM, David Vaughan wrote >> ...and worth also looking at the explicitVariables property in the TD. > > Which should be an excellent idea, but in my experience it is almost > impossible to develop with explicitVariables on in Revolution. I hope > that once 2.0 is released, the RunRev team will consider a consolidation > period to included making their development environment compatible with > this. > > (If David or anyone else has found a way round this problem, I'd love > to hear more.) As I understand it, the only way is for someone to go through the code and declare all the locals. It's a tedious job, but not too difficult, and hopefully they've done this for the v2.0 IDE, or at least plan to. I use explicitVars very rarely, but when I do I find it very useful and since everything running needs to be compliant I'm writing more and more of my tools with explicitVars on to make sure they don't trip anyone up. If you find anything of mine in RevNet or elsewhere that breaks under explicitVars please drop me a note and I'll update it if I haven't already. -- Richard Gaskin Fourth World Media Corporation Developer of WebMerge 2.2: Publish any database on any site ___ [EMAIL PROTECTED] http://www.FourthWorld.com Tel: 323-225-3717 AIM: FourthWorldInc ___ use-revolution mailing list [EMAIL PROTECTED] http://lists.runrev.com/mailman/listinfo/use-revolution
Re: newbies: beware script locals
On Friday, Feb 28, 2003, at 04:01 Australia/Sydney, Ben Rubinstein <[EMAIL PROTECTED]> wrote: on 2/27/03 10:44 AM, David Vaughan wrote ...and worth also looking at the explicitVariables property in the TD. Which should be an excellent idea, but in my experience it is almost impossible to develop with explicitVariables on in Revolution. I hope that once 2.0 is released, the RunRev team will consider a consolidation period to included making their development environment compatible with this. (If David or anyone else has found a way round this problem, I'd love to hear more.) No, I haven't Ben. As the first part of my line said, I usually do not declare handler-local variables so never use the property. regards David Ben Rubinstein | Email: [EMAIL PROTECTED] Cognitive Applications Ltd | Phone: +44 (0)1273-821600 http://www.cogapp.com| Fax : +44 (0)1273-728866 ___ use-revolution mailing list [EMAIL PROTECTED] http://lists.runrev.com/mailman/listinfo/use-revolution
Re: newbies: beware script locals
on 2/27/03 10:44 AM, David Vaughan wrote > ...and worth also looking at the explicitVariables property in the TD. Which should be an excellent idea, but in my experience it is almost impossible to develop with explicitVariables on in Revolution. I hope that once 2.0 is released, the RunRev team will consider a consolidation period to included making their development environment compatible with this. (If David or anyone else has found a way round this problem, I'd love to hear more.) Ben Rubinstein | Email: [EMAIL PROTECTED] Cognitive Applications Ltd | Phone: +44 (0)1273-821600 http://www.cogapp.com| Fax : +44 (0)1273-728866 ___ use-revolution mailing list [EMAIL PROTECTED] http://lists.runrev.com/mailman/listinfo/use-revolution
Re: newbies: beware script locals
On Thursday, Feb 27, 2003, at 20:16 Australia/Sydney, [EMAIL PROTECTED] wrote: Hope this clarifies my meaning. yes it does. so you always declare the variable whether inside or outside the script? that is what seems to be recommended. Recommended, probably, but honoured... more in the breach than the observance in my case. However, it is good practice and worth also looking at the explicitVariables property in the TD. cheers David = [EMAIL PROTECTED]http://www.erikhansen.org ___ use-revolution mailing list [EMAIL PROTECTED] http://lists.runrev.com/mailman/listinfo/use-revolution
Re: newbies: beware script locals
--- David Vaughan <[EMAIL PROTECTED]> wrote: > >> From: erik hansen <[EMAIL PROTECTED]> > wrote: > > > >> Through use of custom props, script > >> locals and ordinary variables, I have been > able > >> to relegate globals to very rare usage, > > > > when would you use "ordinary variables" > instead > > of "script locals"? > > > >> when you actually want a non-persistent > > entirely > >> global variable. Rev is quite rich in > scoping > >> and persistence options. > > > > "persistence" as a programming term is a new > one > > for me. how would a global variable > non-persist? > > > > TIA > > > Erik > > Perhaps I used some casual expression. By > "ordinary variables" I meant > those whose whose scope was a single handler > (declared or first used > within it) rather than "script locals" which > are declared within a > script but outside handlers, thus giving them a > script-wide scope and > session persistence - they retain their value > until the application is > closed or the script recompiled. > > A global variable nominally has script-wide > scope but is also available > in any other script in which it is also > declared, affording it > application-wide scope. A global has session > persistence only, like a > script local, where a custom property persists > through a stack close > (with save if changed)) and re-open. A custom > property can be tied by > definition to various objects from a control to > a stack, which > nominally suggests an intended scope but in > practice they can be > referenced from anywhere. without any other > declaration. > > Hope this clarifies my meaning. yes it does. so you always declare the variable whether inside or outside the script? that is what seems to be recommended. = [EMAIL PROTECTED]http://www.erikhansen.org __ Do you Yahoo!? Yahoo! Tax Center - forms, calculators, tips, more http://taxes.yahoo.com/ ___ use-revolution mailing list [EMAIL PROTECTED] http://lists.runrev.com/mailman/listinfo/use-revolution
Re: newbies: beware script locals
From: erik hansen <[EMAIL PROTECTED]> wrote: Through use of custom props, script locals and ordinary variables, I have been able to relegate globals to very rare usage, when would you use "ordinary variables" instead of "script locals"? when you actually want a non-persistent entirely global variable. Rev is quite rich in scoping and persistence options. "persistence" as a programming term is a new one for me. how would a global variable non-persist? TIA Erik Perhaps I used some casual expression. By "ordinary variables" I meant those whose whose scope was a single handler (declared or first used within it) rather than "script locals" which are declared within a script but outside handlers, thus giving them a script-wide scope and session persistence - they retain their value until the application is closed or the script recompiled. A global variable nominally has script-wide scope but is also available in any other script in which it is also declared, affording it application-wide scope. A global has session persistence only, like a script local, where a custom property persists through a stack close (with save if changed)) and re-open. A custom property can be tied by definition to various objects from a control to a stack, which nominally suggests an intended scope but in practice they can be referenced from anywhere. without any other declaration. Hope this clarifies my meaning. regards David = [EMAIL PROTECTED]http://www.erikhansen.org ___ use-revolution mailing list [EMAIL PROTECTED] http://lists.runrev.com/mailman/listinfo/use-revolution
Re: newbies: beware script locals
on 2/21/03 2:09 PM, Ivers, Doug E wrote > I love script locals, those local declarations at the top of your script > outside of all handlers: > > local myLocalVariable > > [...snip...] > > I use them a lot in my top level script. They are great because I don't have > to declare them in each handler and they are "safer" than globals, if you know > what I mean. > > The caution is that whenever you edit the script, the value of the local goes > away. Yep - specifically, when the script is recompiled, the values of the locals are reset to global. I love them too, so I put up with this. I use one of two strategies to deal with this problem: * either make them self healing - eg if the use of the local is to hold a calculated value which takes a bit of work to calculate, and is then more or less a constant, I have a handler to "ensure they're set", which all applicable routines invoke in set up. This takes care of initialisation when the stack opens or whatever; and also heals, with a small time penalty, when I edit the script during development * or, having made sure that the names are unambiguous (eg "myLocalVariable", or using some prefix or suffix convention that suits you) I simply make them global during development. So I have declarations at the top of a script as apparently contradictory as global locOneThing, locAnotherThing It's only one word to change when I think I've finished mucking about. And during development it's also sometimes helpful because you can inspect the value in the message box. Ben Rubinstein | Email: [EMAIL PROTECTED] Cognitive Applications Ltd | Phone: +44 (0)1273-821600 http://www.cogapp.com| Fax : +44 (0)1273-728866 ___ use-revolution mailing list [EMAIL PROTECTED] http://lists.runrev.com/mailman/listinfo/use-revolution
newbies: beware script locals
Maybe everyone already knows this, but script locals can cause major frustration when debugging... I love script locals, those local declarations at the top of your script outside of all handlers: local myLocalVariable on openStack put 7 into myLocalVariable ... end openStack on mouseUp ... end mouseUp I use them a lot in my top level script. They are great because I don't have to declare them in each handler and they are "safer" than globals, if you know what I mean. The caution is that whenever you edit the script, the value of the local goes away. -- D ___ use-revolution mailing list [EMAIL PROTECTED] http://lists.runrev.com/mailman/listinfo/use-revolution
