local variables
OK this is weird, also in 4.0. A local variable appears to be treated as a global variable. local x, y, myvariable on mouseup put empty into myvariable repeat with x = 1 to 1000 repeat with y = 1 to 1000 put x somefunction(y) return after myvariable end repeat end repeat end mouseup on somefunction y repeat with x = y down to 1 add 1 to y end repeat return y x end somefunction In code that looks a lot like this, x in the mouseup gets reset to 1 after somefunction(y) is called. If x was a global, OK I'd expect that, but I have to declare x a local to use it and it is being treated as a global. Also, x appears twice in the variable section of the debug window. What should I be doing to get the behavior I used to get in 2.9? Thanks, Kee ___ use-revolution mailing list use-revolution@lists.runrev.com Please visit this url to subscribe, unsubscribe and manage your subscription preferences: http://lists.runrev.com/mailman/listinfo/use-revolution
Re: local variables
You are using it as a script variable. It's a local variable that is available from any handler in the script. If you want true local, then put the declaration inside the desired handler sqb - Stephen Barncard San Francisco http://houseofcubes.com/disco.irev 2009/12/28 Kee Nethery k...@kagi.com OK this is weird, also in 4.0. A local variable appears to be treated as a global variable. local x, y, myvariable on mouseup put empty into myvariable repeat with x = 1 to 1000 repeat with y = 1 to 1000 put x somefunction(y) return after myvariable end repeat end repeat end mouseup on somefunction y repeat with x = y down to 1 add 1 to y end repeat return y x end somefunction In code that looks a lot like this, x in the mouseup gets reset to 1 after somefunction(y) is called. If x was a global, OK I'd expect that, but I have to declare x a local to use it and it is being treated as a global. Also, x appears twice in the variable section of the debug window. What should I be doing to get the behavior I used to get in 2.9? Thanks, Kee ___ use-revolution mailing list use-revolution@lists.runrev.com Please visit this url to subscribe, unsubscribe and manage your subscription preferences: http://lists.runrev.com/mailman/listinfo/use-revolution ___ use-revolution mailing list use-revolution@lists.runrev.com Please visit this url to subscribe, unsubscribe and manage your subscription preferences: http://lists.runrev.com/mailman/listinfo/use-revolution
Re: local variables
OK so there are locals that are local to a specific script, and locals to a specific handler. That's interesting. Thank you! Kee Nethery On Dec 28, 2009, at 5:50 PM, stephen barncard wrote: You are using it as a script variable. It's a local variable that is available from any handler in the script. If you want true local, then put the declaration inside the desired handler sqb - Stephen Barncard San Francisco http://houseofcubes.com/disco.irev 2009/12/28 Kee Nethery k...@kagi.com OK this is weird, also in 4.0. A local variable appears to be treated as a global variable. local x, y, myvariable on mouseup put empty into myvariable repeat with x = 1 to 1000 repeat with y = 1 to 1000 put x somefunction(y) return after myvariable end repeat end repeat end mouseup on somefunction y repeat with x = y down to 1 add 1 to y end repeat return y x end somefunction In code that looks a lot like this, x in the mouseup gets reset to 1 after somefunction(y) is called. If x was a global, OK I'd expect that, but I have to declare x a local to use it and it is being treated as a global. Also, x appears twice in the variable section of the debug window. What should I be doing to get the behavior I used to get in 2.9? Thanks, Kee ___ use-revolution mailing list use-revolution@lists.runrev.com Please visit this url to subscribe, unsubscribe and manage your subscription preferences: http://lists.runrev.com/mailman/listinfo/use-revolution ___ use-revolution mailing list use-revolution@lists.runrev.com Please visit this url to subscribe, unsubscribe and manage your subscription preferences: http://lists.runrev.com/mailman/listinfo/use-revolution - I check email roughly 2 to 3 times per business day. Kagi main office: +1 (510) 550-1336 ___ use-revolution mailing list use-revolution@lists.runrev.com Please visit this url to subscribe, unsubscribe and manage your subscription preferences: http://lists.runrev.com/mailman/listinfo/use-revolution
Re: local variables
Kee- Monday, December 28, 2009, 5:50:19 PM, you wrote: You are using it as a script variable. It's a local variable that is available from any handler in the script. If you want true local, then put the declaration inside the desired handler Additionally, you're using y as both a script variable and a parameter passed to somefunction(). -- -Mark Wieder mwie...@ahsoftware.net ___ use-revolution mailing list use-revolution@lists.runrev.com Please visit this url to subscribe, unsubscribe and manage your subscription preferences: http://lists.runrev.com/mailman/listinfo/use-revolution
Script Local Variables not working
Hi all. I discovered an odd thing with script local variables. If I call a function within a card script that uses script local variables, but I call it from the message box, the script local variables are not visible. But if I call the function from an object ON the card, then they ARE visible. I find that odd, because I would have expected local to refer to where the FUNCTION was, i.e. the CARD SCRIPT, not where the function was called from, i.e. the MESSAGE BOX. Does anyone else find this odd? This also have given me fits when debugging because if while stepping through a script, I click on or interact with another object, say the property inspector or message box, and then step through the code again, when I hit a function call in the card script the scope somehow has become the object I clicked on, NOT the card anymore! One would have to be very careful not to interact with any objects while stepping through the code! I get around this by making sure I click back on the stack I am debugging before stepping through the code anymore. Just a heads up. Bob Sneidar IT Manager Logos Management Calvary Chapel CM ___ use-revolution mailing list use-revolution@lists.runrev.com Please visit this url to subscribe, unsubscribe and manage your subscription preferences: http://lists.runrev.com/mailman/listinfo/use-revolution
Re: time shorthand convertor - Is there an advantage to declaring local variables?
If you turn on explicit variable, then you have to. Turning this on can catch some script errors (like misspelled variable names). Otherwise there isn't really any advantage that I can think of. At 12:26 PM 7/28/2006, you wrote: Is there an advantage to declaring local variables? (other than a reminder?) On Jul 27, 2006, at 2:58 PM, Mark Wieder wrote: Cute. I couldn't resist fiddling with it a bit. ON convertTime local t local ampm local t2 Peter T. Evensen http://www.PetersRoadToHealth.com 314-629-5248 or 888-682-4588 ___ use-revolution mailing list use-revolution@lists.runrev.com Please visit this url to subscribe, unsubscribe and manage your subscription preferences: http://lists.runrev.com/mailman/listinfo/use-revolution
Re: time shorthand convertor - Is there an advantage to declaring local variables?
Josh- Friday, July 28, 2006, 10:26:19 AM, you wrote: Is there an advantage to declaring local variables? (other than a reminder?) (taken off line to avoid getting into the religious wars once again) -- -Mark Wieder [EMAIL PROTECTED] ___ use-revolution mailing list use-revolution@lists.runrev.com Please visit this url to subscribe, unsubscribe and manage your subscription preferences: http://lists.runrev.com/mailman/listinfo/use-revolution
What clears script local variables
I'm finding a script local variable is being cleared. I can't figure out where or how. I know setting the script will clear a script local variable. Can anything else? Other than a 'put' and the like? I check at all places it is set to assure it is not empty. The later in something else it comes up empty. All are below the variable in the script. Dar Scott ___ use-revolution mailing list use-revolution@lists.runrev.com Please visit this url to subscribe, unsubscribe and manage your subscription preferences: http://lists.runrev.com/mailman/listinfo/use-revolution
Re: What clears script local variables -- Never mind!
On Jul 26, 2006, at 5:38 PM, Dar Scott wrote: I'm finding a script local variable is being cleared. I can't figure out where or how. I figured it out. -- Dar ___ use-revolution mailing list use-revolution@lists.runrev.com Please visit this url to subscribe, unsubscribe and manage your subscription preferences: http://lists.runrev.com/mailman/listinfo/use-revolution
Re: Problem with declaring local variables
Hi Erik, there is absolutely nothing to be gained by declaring a handler local variable unless one uses explicitVariables. you can set the order in which they appear in VW. you can see at a glance what to look for. I'm not seeing that here: on mouseUp local xValue local aValue put 4 into aValue put 6 into zValue -- undeclared put zValue+aValue into wValue -- undeclared put wValue div 2 into xValue end mouseUp Set debug mode and run handler. Variable Watcher lists: aValue wValue xValue zValue Obviously, they are ordered alphabetically, and I see nothing to indicate some were declared and some weren't. Is there a debug option I'm missing? Rob Cozens CCW, Serendipity Software Company And I, which was two fooles, do so grow three; Who are a little wise, the best fooles bee. from The Triple Foole by John Donne (1572-1631) ___ use-revolution mailing list use-revolution@lists.runrev.com Please visit this url to subscribe, unsubscribe and manage your subscription preferences: http://lists.runrev.com/mailman/listinfo/use-revolution
Re: Problem with declaring local variables
there is absolutely nothing to be gained by declaring a handler local variable unless one uses explicitVariables. Not entirely. Decalring a variable is a simple way of initialising it, to empty unless defined. This can be truly helpful when returning values (in it or in the result), as the value will then be returned and not the name of the pesky little varmit 'cos it slipped through your net! And I *know* you've been there, folks! /H ___ use-revolution mailing list use-revolution@lists.runrev.com Please visit this url to subscribe, unsubscribe and manage your subscription preferences: http://lists.runrev.com/mailman/listinfo/use-revolution
Re: Problem with declaring local variables
--- Rob Cozens [EMAIL PROTECTED] wrote: there is absolutely nothing to be gained by declaring a handler local variable unless one uses explicitVariables. you can set the order in which they appear in VW. you can see at a glance what to look for. Erik Hansen [EMAIL PROTECTED]http://www.erikhansen.org __ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com ___ use-revolution mailing list use-revolution@lists.runrev.com Please visit this url to subscribe, unsubscribe and manage your subscription preferences: http://lists.runrev.com/mailman/listinfo/use-revolution
Re: Problem with declaring local variables
Hi Peter, If a variable is not declared outside a handler, it is assumed to be a handler local variable and reinitialized every time the handler is called. I stand corrected... though in that case there is absolutely nothing to be gained by declaring a handler local variable unless one uses explicitVariables. Rob Cozens CCW, Serendipity Software Company And I, which was two fooles, do so grow three; Who are a little wise, the best fooles bee. from The Triple Foole by John Donne (1572-1631) ___ use-revolution mailing list use-revolution@lists.runrev.com Please visit this url to subscribe, unsubscribe and manage your subscription preferences: http://lists.runrev.com/mailman/listinfo/use-revolution
Re: Problem with declaring local variables
Hi! Have you accidently checked variable checking in the preferences- Script editor? All the best, Malte ___ use-revolution mailing list use-revolution@lists.runrev.com Please visit this url to subscribe, unsubscribe and manage your subscription preferences: http://lists.runrev.com/mailman/listinfo/use-revolution
Re: Problem with declaring local variables
Also make sure you're not using put with a custom property. I had: put someting into the cpCustomProperty of card Some Card and I would get the cannot create variable error. FINALLY I realized I needed to use set with a custom property: set the cpCustomProperty of card Some Card to something Doh! It seems the compiler/syntax checker could produce a more helpful error message in this case... At 08:16 AM 6/7/2006, you wrote: Until now I've had the impression that global variables need to be declared, whereas local variables do not. However, I've just noticed that (using Rev 2.7, Mac OS X) if I don't declare the local variable before the scripting, I get an error message Can't create a variable with that name (explicitvariables). This occurs whether or not explicitvariables is true or false. However, the Rev directions indicate that it should not be necessary to declare local variables if exlpicitvariables is false. Is this a bug? I've also noticed that whereas a previously developed stack may run OK with local variables not declared, that as soon as I make any slight change to the script the error message appears. I recognize that it's a good idea to declare local variables to avoid inadvertent typos in the local variables, but it would seem this need to be addressed correctly in the directions. Steve Goldberg ___ use-revolution mailing list use-revolution@lists.runrev.com Please visit this url to subscribe, unsubscribe and manage your subscription preferences: http://lists.runrev.com/mailman/listinfo/use-revolution Peter T. Evensen http://www.PetersRoadToHealth.com 314-629-5248 or 888-682-4588 ___ use-revolution mailing list use-revolution@lists.runrev.com Please visit this url to subscribe, unsubscribe and manage your subscription preferences: http://lists.runrev.com/mailman/listinfo/use-revolution
Re: Problem with declaring local variables
Hi Steve, Until now I've had the impression that global variables need to be declared, whereas local variables do not. That depends on whether one wants the value of the local variable to persist during runtime: * An undeclared local variable is initialized to empty every time the handler is called. * A declared local variable is initialized at startup. Each time a handler referencing the variable is called, it contains the value it had at the conclusion of the last call. Also, the scope of undeclared variables is always limited to the handler that contains them, whereas the scope of declared [outside the handler] local variables encompasses the entire script that declares them. [But only that script: unlike globals, declared local variables with the same name in different scripts are different variables.] Rob Cozens CCW, Serendipity Software Company And I, which was two fooles, do so grow three; Who are a little wise, the best fooles bee. ___ use-revolution mailing list use-revolution@lists.runrev.com Please visit this url to subscribe, unsubscribe and manage your subscription preferences: http://lists.runrev.com/mailman/listinfo/use-revolution
Re: Problem with declaring local variables
On your second point, do you mean a declared local variable OUTSIDE a handler?I think you are confusing a declared local variable INSIDE a handler with one that is declared OUTSIDE a handler. I don't believe one declare INSIDE a script retains its value: local sRetainsValue = 0 on AddOne add 1 to sRetainsValue put sRetainsValue end AddOne on AddHandler local tDoNotRetainValue = 0 add 1 to tDoesNotRetainValue put tDoesNotRetainValue end AddHandler If you call AddOne, you will get 1, 2, 3, etc. If you call AddHandler, you will always get 1. There is a difference between SCRIPT local, which must be declared, and HANDLER local, which is optionally declared (unless explicitVariables is true). If a variable is not declared outside a handler, it is assumed to be a handler local variable and reinitialized every time the handler is called. At 09:49 AM 6/7/2006, you wrote: Hi Steve, Until now I've had the impression that global variables need to be declared, whereas local variables do not. That depends on whether one wants the value of the local variable to persist during runtime: * An undeclared local variable is initialized to empty every time the handler is called. * A declared local variable is initialized at startup. Each time a handler referencing the variable is called, it contains the value it had at the conclusion of the last call. Also, the scope of undeclared variables is always limited to the handler that contains them, whereas the scope of declared [outside the handler] local variables encompasses the entire script that declares them. [But only that script: unlike globals, declared local variables with the same name in different scripts are different variables.] Rob Cozens CCW, Serendipity Software Company And I, which was two fooles, do so grow three; Who are a little wise, the best fooles bee. ___ use-revolution mailing list use-revolution@lists.runrev.com Please visit this url to subscribe, unsubscribe and manage your subscription preferences: http://lists.runrev.com/mailman/listinfo/use-revolution Peter T. Evensen http://www.PetersRoadToHealth.com 314-629-5248 or 888-682-4588 ___ use-revolution mailing list use-revolution@lists.runrev.com Please visit this url to subscribe, unsubscribe and manage your subscription preferences: http://lists.runrev.com/mailman/listinfo/use-revolution
Re: Problem with declaring local variables
If you are using Constellation - check the checkbox Check Vars at the top of the editor window - I didn't know that was there and also it doesn't sync with the IDE checkbox. This one drove me crazy for weeks. Somehow the checkbox in the Constellation window got set and... I made a fool of myself online... Until now I've had the impression that global variables need to be declared, whereas local variables do not. However, I've just noticed that (using Rev 2.7, Mac OS X) if I don't declare the local variable before the scripting, I get an error message Can't create a variable with that name (explicitvariables). This occurs whether or not explicitvariables is true or false. However, the Rev directions indicate that it should not be necessary to declare local variables if exlpicitvariables is false. Is this a bug? I've also noticed that whereas a previously developed stack may run OK with local variables not declared, that as soon as I make any slight change to the script the error message appears. I recognize that it's a good idea to declare local variables to avoid inadvertent typos in the local variables, but it would seem this need to be addressed correctly in the directions. Steve Goldberg -- stephen barncard s a n f r a n c i s c o - - - - - - - - - - - - ___ use-revolution mailing list use-revolution@lists.runrev.com Please visit this url to subscribe, unsubscribe and manage your subscription preferences: http://lists.runrev.com/mailman/listinfo/use-revolution
Re: Problem with declaring local variables
On 6/7/06 8:00 AM, Peter T. Evensen [EMAIL PROTECTED] wrote: On your second point, do you mean a declared local variable OUTSIDE a handler?I think you are confusing a declared local variable INSIDE a handler with one that is declared OUTSIDE a handler. I don't believe one declare INSIDE a script retains its value: You are correct. global, script local, handler local Some on this list have adopted naming conventions to make this clear in their code what their intentions are: gVarname = global tVarname or lVarname or hVarname= handler local ( t = temporary) sVarname or lVarname = script local pVarname = parameter passed to the handler @Varname = the reference form used let a handler know the memory location rather than make a copy of a large variable I am sure there are many others, as we all adopt our own precise conventions steeped in wisdom :-) Jim Ault Las Vegas ___ use-revolution mailing list use-revolution@lists.runrev.com Please visit this url to subscribe, unsubscribe and manage your subscription preferences: http://lists.runrev.com/mailman/listinfo/use-revolution
Problem with declaring local variables
Yes, Malte. You are absolutely right. By unchecking variable checking in the preferences, the scripting no longer requires me to declare local variables before using them. Thanks! Steve Goldberg In a message dated 6/7/06 2:20:12 PM, [EMAIL PROTECTED] writes: Have you accidently checked variable checking in the preferences- Script editor? ___ use-revolution mailing list use-revolution@lists.runrev.com Please visit this url to subscribe, unsubscribe and manage your subscription preferences: http://lists.runrev.com/mailman/listinfo/use-revolution
Script local variables and initialization.
I think I've discovered something, but if possible I'd like it to be confirmed (or alternatively, to know that I'm wrong, and then I can go back to debugging). I have some script local variables, used in multiple handlers within the card script. I expected them to be reset at start up, and to retain their values from then on - but it appears that they are in fact reset before openCard. (i.e. I call one of the handlers within the card script from preOpenStack, that sets an initial value, but that value appears to be lost. I know it's probably a bad idea to call a card handler from preOpenStack, and I'll be changing that anyway - but it would be reassuring to know that this unconfirmed theory is correct.) The docs are a bit vague The value of a script local variable is retained between handlers, but is lost when you quit the application, when you close the stack (unless its destroyStack property is false), or when the script is re-compiled. which doesn't really mention start-up conditions. Thanks -- Alex. -- No virus found in this outgoing message. Checked by AVG Anti-Virus. Version: 7.0.296 / Virus Database: 265.6.2 - Release Date: 20/12/2004 ___ use-revolution mailing list use-revolution@lists.runrev.com http://lists.runrev.com/mailman/listinfo/use-revolution
Re: Script local variables and initialization.
On Dec 23, 2004, at 1:42 PM, Alex Tweedly wrote: The docs are a bit vague The value of a script local variable is retained between handlers, but is lost when you quit the application, when you close the stack (unless its destroyStack property is false), or when the script is re-compiled. which doesn't really mention start-up conditions. The key word might be re-compiled. I would have thought that it would be re-compiled only once and that at first use. Here is a way to find out if it is being compiled twice and when. Use a later version and put in a new command in the script. Then open the stack on an earlier version that doesn't have the command. You will get an error when it compiles. If it really compiles twice, then you will get it twice. It may be that your send or call fails. Dar ** DSC (Dar Scott Consulting Dar's Lab) http://www.swcp.com/dsc/ Programming Services and Software ** ___ use-revolution mailing list use-revolution@lists.runrev.com http://lists.runrev.com/mailman/listinfo/use-revolution
Re: Script local variables and initialization.
On Dec 23, 2004, at 1:42 PM, Alex Tweedly wrote: (i.e. I call one of the handlers within the card script from preOpenStack, that sets an initial value, but that value appears to be lost. I know it's probably a bad idea to call a card handler from preOpenStack, and I'll be changing that anyway - but it would be reassuring to know that this unconfirmed theory is correct.) Works for me. on preOpenStack put pos into x call setL x of card 2 of me end preOpenStack I would think you can call a card handler from preOpenStack. Did you mean startup? Dar ** DSC (Dar Scott Consulting Dar's Lab) http://www.swcp.com/dsc/ Programming Services and Software ** ___ use-revolution mailing list use-revolution@lists.runrev.com http://lists.runrev.com/mailman/listinfo/use-revolution
Re: Script local variables and initialization.
Dar Scott wrote: The key word might be re-compiled. I would have thought that it would be re-compiled only once and that at first use. Here is a way to find out if it is being compiled twice and when. Use a later version and put in a new command in the script. Then open the stack on an earlier version that doesn't have the command. You will get an error when it compiles. If it really compiles twice, then you will get it twice. I'm not sure if I understood this correctly or not - can I rephrase it and you tell me if that's what you mean, or if I got it wrong ? Use a later version of Rev, and add a newly-added command in the card script. Check that works. Then switch to an earlier version of Rev and load the stack into that; there should be compile errors due to the command which doesn't exist in this earlier version. Yes ? Or no ? Is there a way to find which commands are recently added ? Or any specific suggestions for commands added between 2.2.1 and 2.5 (the only two versions I have). It may be that your send or call fails. Don't think so. The handler in the card script (Display) is called from the preOpenStack to fill in the field values - which it does. There is no other call to it except within button scripts; so the fact that it has values in it strongly suggests it is being successfully called from the preOpenStack - and it is filling in the correct values for record number 1. (Also checked this within debugger - and can see the local variable starting empty and having 1 assigned to it). Then when I click on any of my navigation buttons, Display is called again - but the debugger shows that the local variables are all empty, including the one(s) set in the first time through Display. Moving the call to Display from preOpenStack to openCard SEEMS to fix it - but I'm worried that I'm just pushing some problem into hiding. -- Alex. -- No virus found in this outgoing message. Checked by AVG Anti-Virus. Version: 7.0.296 / Virus Database: 265.6.2 - Release Date: 20/12/2004 ___ use-revolution mailing list use-revolution@lists.runrev.com http://lists.runrev.com/mailman/listinfo/use-revolution
Re: Script local variables and initialization.
On Dec 23, 2004, at 2:51 PM, Dar Scott wrote: call setL x of card 2 of me I also tried send and send in time. Maybe you forgot to Close and Remove from Memory? Dar ** DSC (Dar Scott Consulting Dar's Lab) http://www.swcp.com/dsc/ Programming Services and Software ** ___ use-revolution mailing list use-revolution@lists.runrev.com http://lists.runrev.com/mailman/listinfo/use-revolution
Re: Script local variables and initialization.
This may not be needed; I tried what I thought you said and it worked for me. On Dec 23, 2004, at 2:58 PM, Alex Tweedly wrote: Here is a way to find out if it is being compiled twice and when. Use a later version and put in a new command in the script. Then open the stack on an earlier version that doesn't have the command. You will get an error when it compiles. If it really compiles twice, then you will get it twice. I'm not sure if I understood this correctly or not - can I rephrase it and you tell me if that's what you mean, or if I got it wrong ? Use a later version of Rev, and add a newly-added command in the card script. Check that works. Then switch to an earlier version of Rev and load the stack into that; there should be compile errors due to the command which doesn't exist in this earlier version. Yes ? Or no ? Yes. Is there a way to find which commands are recently added ? Or any specific suggestions for commands added between 2.2.1 and 2.5 (the only two versions I have). Try encrypt. If it is really compiling twice you will see two errors, I assume. If you get no errors, you may have a shadow stack (a term I just made up) in memory. Quit Revolution and reopen the stack. This test may not be needed. I tried something trivial and it worked for me on 2.5 on OS X. Dar ** DSC (Dar Scott Consulting Dar's Lab) http://www.swcp.com/dsc/ Programming Services and Software ** ___ use-revolution mailing list use-revolution@lists.runrev.com http://lists.runrev.com/mailman/listinfo/use-revolution
Re: Script local variables and initialization.
Dar Scott wrote: On Dec 23, 2004, at 1:42 PM, Alex Tweedly wrote: (i.e. I call one of the handlers within the card script from preOpenStack, that sets an initial value, but that value appears to be lost. I know it's probably a bad idea to call a card handler from preOpenStack, and I'll be changing that anyway - but it would be reassuring to know that this unconfirmed theory is correct.) Works for me. on preOpenStack put pos into x call setL x of card 2 of me end preOpenStack I would think you can call a card handler from preOpenStack. Did you mean startup? No, I did mean preOpenStack, but this example works for me too. Darn ! - it seemed like a decent theory :-( OK - back to debugging .. Many thanks ! -- Alex. -- No virus found in this outgoing message. Checked by AVG Anti-Virus. Version: 7.0.296 / Virus Database: 265.6.2 - Release Date: 20/12/2004 ___ use-revolution mailing list use-revolution@lists.runrev.com http://lists.runrev.com/mailman/listinfo/use-revolution
Re: Script local variables and initialization.
On Dec 23, 2004, at 10:04 PM, [EMAIL PROTECTED] wrote: From: Dar Scott [EMAIL PROTECTED] Subject: Re: Script local variables and initialization. To: How to use Revolution use-revolution@lists.runrev.com Message-ID: [EMAIL PROTECTED] Content-Type: text/plain; charset=US-ASCII; format=flowed On Dec 23, 2004, at 1:42 PM, Alex Tweedly wrote: The docs are a bit vague The value of a script local variable is retained between handlers, but is lost when you quit the application, when you close the stack (unless its destroyStack property is false), or when the script is re-compiled. which doesn't really mention start-up conditions. The key word might be re-compiled. I would have thought that it would be re-compiled only once and that at first use. Here is a way to find out if it is being compiled twice and when. Use a later version and put in a new command in the script. Then open the stack on an earlier version that doesn't have the command. You will get an error when it compiles. If it really compiles twice, then you will get it twice. It gets recompiled whenever you edit a script and click Apply. So, if you've initialized something in openCard or preOpenCard, or some other pre or open handler, then edit the script, the variables will become uninitialized. -- Frank Web Photos Pro: Software for Photo Bloggers and Other Photo Power Users See us on the web at http://www.webphotospro.com/ ___ use-revolution mailing list use-revolution@lists.runrev.com http://lists.runrev.com/mailman/listinfo/use-revolution
Re: Global /local variables
--- Ken Ray [EMAIL PROTECTED] wrote: Locals are the same as globals, except that they cannot have a scope outside of a single script. If you declare them inside of a handler, they apply only to that handler. If you declare them inside of a script, they are available to any handler in that script only. Other scripts don't see them. i like declaring locals mainly to control the order in which the variables are displayed during debugging. are there any other important reasons for declaring locally? = [EMAIL PROTECTED]http://www.erikhansen.org __ Do you Yahoo!? U2 on LAUNCH - Exclusive greatest hits videos http://launch.yahoo.com/u2 ___ use-revolution mailing list [EMAIL PROTECTED] http://lists.runrev.com/mailman/listinfo/use-revolution
Global /local variables
I do not understand the real meaning of global and local variables in Revolution... The info about declaring variables outside a handler seems to be equal in both cases... :-( From the local¹ entry in Revolution Help system: You can also use the local command in a script, outside any handlers in the script. These local variables can be used by any handler in that script, without needing to be declared in the handler itself, and their values are maintained from handler to handler From the global¹ entry in Revolution Help system: You can also place a global command in a script, but outside any handlers in the script. These globals can be used by any handler in that script, without needing to be declared in the handler itself. André ___ use-revolution mailing list [EMAIL PROTECTED] http://lists.runrev.com/mailman/listinfo/use-revolution
Re: Global /local variables
Imagine you have a button, and in it's script you have several handlers: mouseUp, processData, doMoreStuff etc. If you put a local variable in the button's script but OUTSIDE any of the handlers - say on the first line - then all of these handlers can access the data stored in that variable. However no other scripts e.g. card script, stack script, another button's script - can access that variable. If they declare a local variable even using the same variable name, it will refer to a new variable. If instead of local, you declared that variable as global, then any handler in any script could access it, either by declaring it inside the handler or in the script but outside the handler. Cheers, Sarah On Monday, November 11, 2002, at 08:06 am, Andre Rombauts wrote: I do not understand the real meaning of global and local variables in Revolution... The info about declaring variables outside a handler seems to be equal in both cases... :-( From the local¹ entry in Revolution Help system: You can also use the local command in a script, outside any handlers in the script. These local variables can be used by any handler in that script, without needing to be declared in the handler itself, and their values are maintained from handler to handler From the global¹ entry in Revolution Help system: You can also place a global command in a script, but outside any handlers in the script. These globals can be used by any handler in that script, without needing to be declared in the handler itself. André ___ use-revolution mailing list [EMAIL PROTECTED] http://lists.runrev.com/mailman/listinfo/use-revolution ___ use-revolution mailing list [EMAIL PROTECTED] http://lists.runrev.com/mailman/listinfo/use-revolution
Re: Global /local variables
Andre, For global commands, you have two choices: Inside handlers or outside. If you declare a global inside of a handler, each handler that wants to access that global needs to declare that same variable to get access to it. For example: on DoStuff1 global gVar put 10 into gVar end DoStuff 1 on DoStuff2 put gVar end DoStuff2 -- Puts nothing, since DoStuff2 doesn't know about gVar. If the handler was: on DoStuff2 global gVar put gVar end DoStuf2 -- Puts 10 since it knows about gVar by declaring global gVar However, if you put it *outside* handlers in the script, all handlers already know about the global, so you could do this: global gVar on DoStuff1 put 10 into gVar end DoStuff1 on DoStuff2 put gVar end DoStuff 2 -- Puts 10. Since global variables are global, you can access that same gVar variable in another script entirely through one of the two methods above. So if in another script you had: on DoStuff3 global gVar put gVar end DoStuff3 -- Puts 10. Locals are the same as globals, except that they cannot have a scope outside of a single script. If you declare them inside of a handler, they apply only to that handler. If you declare them inside of a script, they are available to any handler in that script only. Other scripts don't see them. Hope this helps, Ken Ray Sons of Thunder Software Email: [EMAIL PROTECTED] Web Site: http://www.sonsothunder.com/ - Original Message - From: Andre Rombauts [EMAIL PROTECTED] To: revolution [EMAIL PROTECTED] Sent: Sunday, November 10, 2002 4:01 PM Subject: Global /local variables I do not understand the real meaning of global and local variables in Revolution... The info about declaring variables outside a handler seems to be equal in both cases... :-( From the Olocal¹ entry in Revolution Help system: You can also use the local command in a script, outside any handlers in the script. These local variables can be used by any handler in that script, without needing to be declared in the handler itself, and their values are maintained from handler to handler From the Oglobal¹ entry in Revolution Help system: You can also place a global command in a script, but outside any handlers in the script. These globals can be used by any handler in that script, without needing to be declared in the handler itself. André ___ use-revolution mailing list [EMAIL PROTECTED] http://lists.runrev.com/mailman/listinfo/use-revolution ___ use-revolution mailing list [EMAIL PROTECTED] http://lists.runrev.com/mailman/listinfo/use-revolution
