Re: Show globals
Bob, et al: A couple of follow up thoughts: And script local variables cannot be accidentally or purposely read or changed by scripts in other stacks or other objects. This may not mean much if you are developing end user applications; however if you are building libraries that may be used by other Rev developers, it is a significant plus. any script local variable can be accessed by handlers in other scripts or stacks, if the script declaring the local variable includes a getValue function and a setValue command for that variable. Eg: local mySharedVariable function getValue return mySharedVariable end getValue on setValue newValue put newValue into mySharedVariable end setValue The examples I gave are very generic. In the real world one might script specific get and set handlers: local mySharedVariable local anotherSharedValue function getMySharedVariable return mySharedVariable end getMySharedVariable on setAnotherSharedValue newValue put newValue into anotherSharedValue end or something a little more generic like: function getValue variableName switch variableName case mySharedVariable return mySharedVariable case anotherSharedValue return anotherSharedValue end switch return empty --or an error end getVal;ue on setValue variableName, newValue switch variableName case mySharedVariable put newValue into mySharedVariable break case anotherSharedValue put newValue into anotherSharedValue break end switch end getVal;ue I don't know if do will do the job: function getValue variableName do putvariableNameinto theValue return theValue end getValue because I don't do dos and wonder if code compiled a runtime can access script local variables. If shared script local variables reside in the stack script, then handlers such as those above allow access to the variables from every other handler in the stack. If the script locals reside on an interior control, one might want to script getValue as a command which can be sent by other handlers elsewhere in the stack: on getMySharedVariable return mySharedVariable end getMySharedVariable Where the calling handler could... send getMySharedVariable to reference to control whose script contains\ the variable put the result into mySharedVariableCopy 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: Show globals
Oh I see how that works. That makes sense for distributed developer tools. You are preventing unintended changes to your internal variables from the the outside world while providing a mechanism for accessing them if needed. I never understood Script Local variables until now. Bob Sneidar IT Manager Logos Management Calvary Chapel CM On Dec 12, 2008, at 9:02 AM, Rob Cozens wrote: Bob, et al: A couple of follow up thoughts: And script local variables cannot be accidentally or purposely read or changed by scripts in other stacks or other objects. This may not mean much if you are developing end user applications; however if you are building libraries that may be used by other Rev developers, it is a significant plus. any script local variable can be accessed by handlers in other scripts or stacks, if the script declaring the local variable includes a getValue function and a setValue command for that variable. Eg: local mySharedVariable function getValue return mySharedVariable end getValue on setValue newValue put newValue into mySharedVariable end setValue The examples I gave are very generic. In the real world one might script specific get and set handlers: local mySharedVariable local anotherSharedValue function getMySharedVariable return mySharedVariable end getMySharedVariable on setAnotherSharedValue newValue put newValue into anotherSharedValue end or something a little more generic like: function getValue variableName switch variableName case mySharedVariable return mySharedVariable case anotherSharedValue return anotherSharedValue end switch return empty --or an error end getVal;ue on setValue variableName, newValue switch variableName case mySharedVariable put newValue into mySharedVariable break case anotherSharedValue put newValue into anotherSharedValue break end switch end getVal;ue I don't know if do will do the job: function getValue variableName do putvariableNameinto theValue return theValue end getValue because I don't do dos and wonder if code compiled a runtime can access script local variables. If shared script local variables reside in the stack script, then handlers such as those above allow access to the variables from every other handler in the stack. If the script locals reside on an interior control, one might want to script getValue as a command which can be sent by other handlers elsewhere in the stack: on getMySharedVariable return mySharedVariable end getMySharedVariable Where the calling handler could... send getMySharedVariable to reference to control whose script contains\ the variable put the result into mySharedVariableCopy 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 ___ 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: Show globals
The big thing about globals for me, even more than their scope, is their persistence. I can declare a global and check it's current value in the message box without any script even running. They are the only way to do environment variables, where the state of various things can be maintained long term while the applications is running (an odd concept in Revolution since nothing the user creates is actually running most of the time.) For that reason alone I rely heavily on globals. I would only use script local variables for temporary variables that only need to live while the script runs. For any serious application which makes heavy use of variables, globals are almost the defacto storage medium. I can see how it would be a real problem for a complex application to bog down when debugging. Bob Sneidar IT Manager Logos Management Calvary Chapel CM On Dec 10, 2008, at 2:44 PM, Richard Gaskin wrote: Another might be to reconsider the need for such globals, perhaps opting for script-local variables for those values only needed by a single script. ___ 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: Show globals
Bob, et al: I would only use script local variables for temporary variables that only need to live while the script runs The Rev Dictionary says: The difference between a script local variable and a global variable is that a script local variable can only be used in the handlers of one script, while a global variable can be used in any handler or script with a global declaration for that variable. . [snip] 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. So script local variables have value persistence so long as the stack or app remains open. And script local variables cannot be accidentally or purposely read or changed by scripts in other stacks or other objects. Having said the latter, I would note that any script local variable can be accessed by handlers in other scripts or stacks, if the script declaring the local variable includes a getValue function and a setValue command for that variable. Eg: local mySharedVariable function getValue return mySharedVariable end getValue on setValue newValue put newValue into mySharedVariable end setValue Rob Cozens, CCW Serendipity Software Company Vive R 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 :Show Globals
Hi from Paris, Fred, Even before Rev 3.0 came out to efficiently hide the global variables, I had wanted to see such information easily. Now that Rev 3.0 is here, I'm glad I did it. I use the following subterfuge : I build my stacks using one of many existing models. All of my models contain a hidden button. This button shows and hides the following buttons : SHOWVAR, SHOWFIELD, SHOWBUTTON, SHOWGROUP, SHOWGRAPH With these buttons, and using a (hidden) scroll field, I can display or hide the names of all declared globals, fields, buttons, etc. When building these lists, I strip out $variables, and any other names I wish, check field and button names, ensure no duplicate names (I can be a little forgetful). Like Jim, I use a strict naming system, at a glance, you can see what you want. Very useful information when you are building and testing your stacks. When the stack goes live, hide everthing you don't want to see. It will be available in the future if you update the stack. However, I don't know how to show globals assigned ONLY to the current stack. Does anybody know ? If you want the scripts, catch me off-list .. -Francis Nothing should ever be done for the first time ! ___ 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: Show Globals
Francis Nugent Dixon wrote: However, I don't know how to show globals assigned ONLY to the current stack. Does anybody know ? I'm not sure what you mean. Globals are global in scope, available to any script with a matching global declaration. -- Richard Gaskin Fourth World Revolution training and consulting: http://www.fourthworld.com Webzine for Rev developers: http://www.revjournal.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: Show Globals
On 12/10/08 8:24 AM, Richard Gaskin [EMAIL PROTECTED] wrote: Francis Nugent Dixon wrote: However, I don't know how to show globals assigned ONLY to the current stack. Does anybody know ? I'm not sure what you mean. Globals are global in scope, available to any script with a matching global declaration. -- Richard Gaskin Richard is pointing out that globals are, well, global to the Rev environment. In fact, they are variables that are the property of the Rev app, not any one stack or stack file. This means that if you declare a global, fill it with a pony, the pony won't die until you quit Rev or delete the global by using... delete global gANiceWarmStable It feels better to fill globals with things like the unexpectedly-high heating bill, then quit Rev. The default is that globals live in memory as long as Rev is running. 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
Re: Show Globals
Francis Nugent Dixon wrote: However, I don't know how to show globals assigned ONLY to the current stack. Does anybody know ? Richard Gaskin wrote: I'm not sure what you mean. Globals are global in scope, available to any script with a matching global declaration. Yes, but why would anyone want to see them when debugging a script that doesn't refer to them? For example, if I have a button whose script is: on mouseup global gBeginTime put the time into gBeginTime put the date into tDate end mouseup When debugging this, I want to see the following variable list: gBeginTime 11:24 PM tDate 11/18/08 Instead I see a gigantic list of globals that have been called by other stacks (I am creating a very complex set of stacks that run my business.) Simply scrolling down from gBeginTime and tDate will take forever and it's really confusing because you click on the scrollbar and nothing happens for over 5 seconds, and you're not sure you clicked on the scrollbar, so you click again, and then when it finally scrolls, it's gone too far. It is a similar situation when I press the scroll arrows or drag the slider. With all of these globals listed, there are these long delays. ___ 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: Show Globals
On Dec 10, 2008, at 12:54 PM, Fred moyer wrote: Francis Nugent Dixon wrote: However, I don't know how to show globals assigned ONLY to the current stack. Does anybody know ? Richard Gaskin wrote: I'm not sure what you mean. Globals are global in scope, available to any script with a matching global declaration. Yes, but why would anyone want to see them when debugging a script that doesn't refer to them? For example, if I have a button whose script is: on mouseup global gBeginTime put the time into gBeginTime put the date into tDate end mouseup When debugging this, I want to see the following variable list: gBeginTime 11:24 PM tDate 11/18/08 Instead I see a gigantic list of globals that have been called by other stacks (I am creating a very complex set of stacks that run my business.) Simply scrolling down from gBeginTime and tDate will take forever and it's really confusing because you click on the scrollbar and nothing happens for over 5 seconds, and you're not sure you clicked on the scrollbar, so you click again, and then when it finally scrolls, it's gone too far. It is a similar situation when I press the scroll arrows or drag the slider. With all of these globals listed, there are these long delays. Fred, Didn't you say you're on Rev 3.0? Did you uncheck the Show Globals option in the script editor preferences? (I'm coming in to the discussion late, so I apologize if someone already addressed this.) Devin Devin Asay Humanities Technology and Research Support Center Brigham Young University ___ 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: Show globals
Hi from Paris, Sorry Richard, my explanation was vague. Launch a standalone, of any single stack, and look at the global variables as I do, and you see only those currently assigned to the stack (obviously). In the IDE, open several stacks at once, switching from one stack to another, and in any of the stacks, you see the total list of globals defined by all current stacks, and you don't know which globals belong to which stack. Best Regards -Francis ___ 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: Show globals
Francis Nugent Dixon wrote: In the IDE, open several stacks at once, switching from one stack to another, and in any of the stacks, you see the total list of globals defined by all current stacks, and you don't know which globals belong to which stack. It seems appropriate that the Message Box shows all globals, since they're global in scope and available to every script running during the session. The IDE itself shows only a very few globals, so I'm assuming the ones you're seeing are for your own stacks, yes? If so, one solution might be to consider using arrays, where you store values for a given stack as elements in a single global. Another might be to reconsider the need for such globals, perhaps opting for script-local variables for those values only needed by a single script. -- Richard Gaskin Richard Gaskin Fourth World Revolution training and consulting: http://www.fourthworld.com Webzine for Rev developers: http://www.revjournal.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: Show Globals
Hello, again Fred, Since you said you are using a complex of stacks to run your business, you are probably in the category of needing to move away from globals and to something like SQL or Valentina rather than hold all the data in memory. Custom properties are in RAM when the stack containing them is in memory, which is why they are so fast. The same goes for the multi-dimensional arrays that are new to Rev 3.0+ The slowness might be that the debugging fields are trying to load the first 100 chars in a very large number of filled variables and globals. Why not try something like this for your larger globals? on mouseup set the beginTime of stack dataCache to the time set the tDate of stack dataCache to the date end mouseup Here is another version that is a little more compact and useful: on mouseup setValue the time, beginTime, dataCache, put the date into tDate end mouseup This might speed things up quite a bit for you without SQL. To see a working version in a stack, copy the lines below. start copy - --paste into a new stack script --save as dataCache.rev --then double click on mousedoubleup setValue the time, beginTime, dataCache, -- a procedure get the result; breakpoint --use this for debugging the new value in the IT variable setValue (the time space), sequenceTime, dataCache, before -- this is a procedure call get the result; breakpoint --use this for debugging the new value in the IT variable put the date into tDate --local to this handler put getValue(beginTime, dataCache) into it -- this is a function call breakpoint end mousedoubleup -- support handlers -- --put this script into back and it will be available to all handlers -- in any stack on setValue val, var, where, place if place is empty then set the var of stack where to val else if place is before then set the var of stack where to (val the var of stack where) else if place is after then set the var of stack where to (the var of stack where val) end if return the var of stack where end setValue function getValue var, where return the var of stack where end getValue -- end copy - On 12/10/08 11:54 AM, Fred moyer [EMAIL PROTECTED] wrote: Francis Nugent Dixon wrote: However, I don't know how to show globals assigned ONLY to the current stack. Does anybody know ? Richard Gaskin wrote: I'm not sure what you mean. Globals are global in scope, available to any script with a matching global declaration. Yes, but why would anyone want to see them when debugging a script that doesn't refer to them? For example, if I have a button whose script is: on mouseup global gBeginTime put the time into gBeginTime put the date into tDate end mouseup When debugging this, I want to see the following variable list: gBeginTime 11:24 PM tDate 11/18/08 Instead I see a gigantic list of globals that have been called by other stacks (I am creating a very complex set of stacks that run my business.) Simply scrolling down from gBeginTime and tDate will take forever and it's really confusing because you click on the scrollbar and nothing happens for over 5 seconds, and you're not sure you clicked on the scrollbar, so you click again, and then when it finally scrolls, it's gone too far. It is a similar situation when I press the scroll arrows or drag the slider. With all of these globals listed, there are these long delays. ___ 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
Show Globals
Hi everyone. Am I the only one for whom the script editor on 3.0 is glacially slow? It is almost impossible at times to code, especially when I have lots of huge globals loaded. For that matter, in Preferences, it seems that checking or unchecking Show Globals in the Script Editor area makes no difference. I still see all of my globals (as well as $User and other $ variables) listed. Simply comparing 2 variables if they start with say A and Z can take 20 seconds or more. Stepping through scripts is also unbelievably slow. All of this wouldn't be so bad if the variables were not locked underneath the script so that the variable list by definition must be short requiring lots of scrolling up and down. Are there any workarounds? For example: - Is it possible for example to truly not see globals that are not referred to in a particular script? - Is it possible to have Revolution use the old style script editor? (I notice that the present script editor is called revNewScriptEditor which implies an element of experimentation.) - Is it possible to drag the Variable list away from the window? Incidentally, I noticed when starting to report a bug today, I saw that one of the choices was Revolution 3.5.0 Is there a new version available?? Thanks Fred Moyer ___ 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: Show Globals
A couple comments about global variables and variable watcher. 1) I am using 2.9 so I don't see the 'slow' behavior 2) I prefix all my globals with 'z' and my script locals with 'x' so that they sort to the bottom of the watcher window. 3) you can use the 'page up' ' page down' keys to jump after you have clicked somewhere on the variable watcher window, although slow scrolling may still occur. 4) if you don't need to see the contents of the globals during debugging, why not try using custom properties? This works more easily if you are always using one main stack and one property set but may not change the slow performance. Hope this gives you and idea or two. Jim Ault Las Vegas On 12/9/08 4:07 PM, Fred moyer [EMAIL PROTECTED] wrote: Hi everyone. Am I the only one for whom the script editor on 3.0 is glacially slow? It is almost impossible at times to code, especially when I have lots of huge globals loaded. For that matter, in Preferences, it seems that checking or unchecking Show Globals in the Script Editor area makes no difference. I still see all of my globals (as well as $User and other $ variables) listed. Simply comparing 2 variables if they start with say A and Z can take 20 seconds or more. Stepping through scripts is also unbelievably slow. All of this wouldn't be so bad if the variables were not locked underneath the script so that the variable list by definition must be short requiring lots of scrolling up and down. Are there any workarounds? For example: - Is it possible for example to truly not see globals that are not referred to in a particular script? - Is it possible to have Revolution use the old style script editor? (I notice that the present script editor is called revNewScriptEditor which implies an element of experimentation.) - Is it possible to drag the Variable list away from the window? Incidentally, I noticed when starting to report a bug today, I saw that one of the choices was Revolution 3.5.0 Is there a new version available?? Thanks Fred Moyer ___ 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: Show Globals
Fred moyer wrote: Hi everyone. Am I the only one for whom the script editor on 3.0 is glacially slow? It is almost impossible at times to code, especially when I have lots of huge globals loaded. I don't see any slowdown particularly. Do you have enough RAM? I'm just guessing, but maybe Rev is having to swap memory out to disk a lot if there are a lot of big globals. You could test this by opening a stack that uses no globals and try debugging it. If it's snappy, then there may be a memory issue with the other stacks. Huge globals will deplete available RAM pretty quickly. If there is any other way to store those values, do it. It is easy to use up nearly all available memory if you open a few stacks and each one loads a big global variable and never removes it. If there is no other way to store these values, then put empty into the globals when they aren't needed any more, or delete them entirely. For that matter, in Preferences, it seems that checking or unchecking Show Globals in the Script Editor area makes no difference. I still see all of my globals (as well as $User and other $ variables) listed. Simply comparing 2 variables if they start with say A and Z can take 20 seconds or more. Unchecking show globals works okay here. You could also try unchecking Revolution UI elements appear in lists. That should remove the gRev-whatevers at least. Stepping through scripts is also unbelievably slow. I see a very brief pause, but that's built into the debugger on purpose so you can see what's happening. It feels fine to me. A major slowdown might be related to the same RAM issue though, I'd try testing with a simple, no-globals stack and see if the speed picks up. All of this wouldn't be so bad if the variables were not locked underneath the script so that the variable list by definition must be short requiring lots of scrolling up and down. Are there any workarounds? For example: - Is it possible for example to truly not see globals that are not referred to in a particular script? - Is it possible to have Revolution use the old style script editor? (I notice that the present script editor is called revNewScriptEditor which implies an element of experimentation.) - Is it possible to drag the Variable list away from the window? None of this is possible yet. I want the same things. The variable watcher is too small for me to see comfortably. There is a request in the QCC with all these suggestions and more. Incidentally, I noticed when starting to report a bug today, I saw that one of the choices was Revolution 3.5.0 Is there a new version available?? Not yet. I think they're probably just numbering ahead. -- Jacqueline Landman Gay | [EMAIL PROTECTED] HyperActive Software | http://www.hyperactivesw.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: Show Globals
The script editor is just fine as long as you don't need to debug anything complex. Once you've got more than a few variables, and particularly if these include multidimensional arrays it bogs down horribly. It needs some attention I reckon! Terry... On 10/12/08 4:03 PM, J. Landman Gay [EMAIL PROTECTED] wrote: Fred moyer wrote: Hi everyone. Am I the only one for whom the script editor on 3.0 is glacially slow? It is almost impossible at times to code, especially when I have lots of huge globals loaded. I don't see any slowdown particularly. Do you have enough RAM? I'm just guessing, but maybe Rev is having to swap memory out to disk a lot if there are a lot of big globals. You could test this by opening a stack that uses no globals and try debugging it. If it's snappy, then there may be a memory issue with the other stacks. -- Dr Terry Judd Lecturer in Educational Technology (Design) Biomedical Multimedia Unit Faculty of Medicine, Dentistry Health Sciences The University of Melbourne Parkville VIC 3052 AUSTRALIA 61-3 8344 0187 ___ 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
