Re: Initializing local properties
Ah, c'mon Mark... we haven't had a good globals rant on this list in quite some time! And as long as it doesn't degrade into a religious war, we might learn something - especially the newer folks. Phil Davis Mark Wieder wrote: Why are globals so unloved? ...don't get me started... -- Phil Davis PDS Labs Professional Software Development http://pdslabs.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
Variable hiding (was Initializing local properties)
Because they take up so much space in the debugger's variable tab. It would be nice to be able to hide certain variables, or at least rearrange them. Anyone think this is a good idea, to be able to see only the variables you want to while debugging? This in the actual tab. I know and love the separate windows for chosen vars. Craig Newman In a message dated 4/28/09 1:45:50 PM, rev...@pdslabs.net writes: Why are globals so unloved? ** Access 350+ FREE radio stations anytime from anywhere on the web. Get the Radio Toolbar! (http://toolbar.aol.com/aolradio/download.html?ncid=emlcntusdown0003) ___ 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
Initializing local properties
AFAIK - there is no easy or robust way to initialise local variables? That is you can't do something like: local thisWorks = some long complicated result local thisDoesnt = getComplicatedResult() function getComplicatedResult return some long complicated result end getComplicatedResult You could initialize things on a preopencard - but this would not allow for it's use when called from another stack - as in defining a custom property put the complicated_Result of btn 1 of stack Test I think there is no way to do this with locals - so you have to functions or properties and calculate them each time for a handler? Using a global would be over-cluttering things. ___ 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: Initializing local properties
David Bovill wrote: AFAIK - there is no easy or robust way to initialise local variables? That is you can't do something like: local thisWorks = some long complicated result local thisDoesnt = getComplicatedResult() function getComplicatedResult return some long complicated result end getComplicatedResult There's a request for this in the RQCC: http://quality.runrev.com/qacenter/show_bug.cgi?id=1241 You could initialize things on a preopencard - but this would not allow for it's use when called from another stack - as in defining a custom property put the complicated_Result of btn 1 of stack Test I think there is no way to do this with locals - so you have to functions or properties and calculate them each time for a handler? Using a global would be over-cluttering things. Why are globals so unloved? Most programming languages support them so they can be accessed globally. If you need global access, why not use a global? -- 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: Initializing local properties
2009/4/15 Richard Gaskin ambassa...@fourthworld.com There's a request for this in the RQCC: http://quality.runrev.com/qacenter/show_bug.cgi?id=1241 Voted for - would be great if others could! Why are globals so unloved? Most programming languages support them so they can be accessed globally. If you need global access, why not use a global? True - some of my allergy to them is not rational :) In this case I'm trying to speed up the script so the behaviors of the view library I'm working on. I have about 50 views at the moment, which I'm going through and tidying. Each view has a complex geometry / behavior script which refers to controls within the view - on average maybe 4 controls for each view. I'd expect the library will eventually have a few hundred widgets in - using globals would mean creating say 800 global variables or I guess an array with 800 entries. Then I'd have to make sure there were no name clashes... etc But most of all it does not solve the problem of initializing the variables. I don't want to create a complex mechanism that loads and maintains this stuff for every script, writing preopen card handlers and getting errors every time I miss one out. I want to define them in the context of the only place they are used - the script of the behavior - and I want them to be initialised when and only they are used - simply by me defining them in the 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: Initializing local properties
Richard- Wednesday, April 15, 2009, 8:14:27 AM, you wrote: David Bovill wrote: AFAIK - there is no easy or robust way to initialise local variables? There's a request for this in the RQCC: http://quality.runrev.com/qacenter/show_bug.cgi?id=1241 However, notice in bz #1241 (filed in February of... cough... 2004) that you *can* initialize local variables to string values. Why are globals so unloved? ...don't get me started... -- -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
Re: Initializing local properties
David Bovill wrote: 2009/4/15 Richard Gaskin wrote: Why are globals so unloved? Most programming languages support them so they can be accessed globally. If you need global access, why not use a global? True - some of my allergy to them is not rational :) In this case I'm trying to speed up the script so the behaviors of the view library I'm working on. I have about 50 views at the moment, which I'm going through and tidying. Each view has a complex geometry / behavior script which refers to controls within the view - on average maybe 4 controls for each view. I'd expect the library will eventually have a few hundred widgets in - using globals would mean creating say 800 global variables or I guess an array with 800 entries. Then I'd have to make sure there were no name clashes... etc I wonder if v3.5's behaviors would help with that. One script, one set of var declarations, instantiated as needed for every object that uses it. But most of all it does not solve the problem of initializing the variables. I don't want to create a complex mechanism that loads and maintains this stuff for every script, writing preopen card handlers and getting errors every time I miss one out. I want to define them in the context of the only place they are used - the script of the behavior - and I want them to be initialised when and only they are used - simply by me defining them in the script. While we wait for the ability to initialize vars from a function call, a single Init handler in a behavior script may do the trick for now. If you used a script-local var as a flag to see if it's been initialized, you could ensure it's initialized only once even if called from a preOpenCard handler: local sInited on preOpenCard if sInited is empty then -- do initialization stuff put true into sInited end if pass preOpenCard end preOpenCard -- 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: Initializing local properties
2009/4/15 Richard Gaskin ambassa...@fourthworld.com While we wait for the ability to initialize vars from a function call, a single Init handler in a behavior script may do the trick for now. If you used a script-local var as a flag to see if it's been initialized, you could ensure it's initialized only once even if called from a preOpenCard handler: local sInited on preOpenCard if sInited is empty then -- do initialization stuff put true into sInited end if pass preOpenCard end preOpenCard Yes - but as in the example I gave the custom property is being called from outside of the current stack - so no preOpenCard message is sent - and unfortnuately we don't have any load type messages that we can trap when a stack gets loaded into memory - only when it is opened. I want the properties I define to be as close as possible to 100% bullet proof - and callable from aywhere in the environment. A use case for instance would be you have a library of a hundred view widgets - they are ot laoded into memory but sitting on the local hard disk, and indexed in the stackfiles. A script want to be able to get or set one of the views behavior in a natural syntax - ie: put the long id of grp 1 of stack Outliner into someView if the view_Type of someview is tree then addToIndex copy someView to this card And not care if is already open or this is the first time it is opening - there is nothing you can do about this other than load everything into memory on startup - or call functions and getprops dynamically (which loses the elegance and speed advantages of doing it once and loading it into a local variable. ___ 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
