Re: Naming Custom Properties
On 17 Apr 2010, at 00:39, Vokey, John wrote: set the fred of this stack to myArray put fred into mary; set the mary of this stack to myArray do the same thing. The line set the fred of this stack to myArray should throw an error if fred is empty. Unfortunately, nobody at RunRev seems to agree with my desire for a consistent syntax. Some history from my woolly memory. I think that at one time, you couldn't set a custom property using a variable. (Some time before Metacard 2.5) So the following... put mary into fred set the fred of me to abc would have created a property named fred. The decision to allow using variables was to support the then fledgling Revolution IDE (Before RunRev acquired the Metacard engine). The case was made that this really speeded up the massive setting of properties, which is what the Rev IDE does at times. Scott Raney was aware of potential problems and asked on the list whether there were any strong objections to the change. I think the general opinion was that the benefits outweighed the problems. I tend to agree, and have made frequent use of this feature. (Previously you had to construct ugly do statements to convert the variable contents to the property name.) I understand the logic behind your idea for requiring custom property names to be quoted. But it would create an oddity where built-in properties would not require quotes and custom properties would. set the height of me to 123 set the cHeight of me to 456 It would presumably break many existing stacks too. Overall, I think I prefer the current behavior. Cheers Dave___ 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: Naming Custom Properties
Vokey, John wrote: However, to be consistent, the name of the custom property should be a quoted literal when not the contents of a variable name You would be right if quoting literals was mandatory. It is not, although AFAIAC quoting is strongly recommended. Robert ___ 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
Naming Custom Properties
Hello everyone, I vaguely, very vaguely, recall that a custom property should have a name that is different from the variable to which it is being set. So, for example, if myArray is the variable, then set the myPropArray of this stack to myArray is fine, but set the myArray of this stack to myArray does not set anything apparently. I waisted a big chunk (no xTalk pun intended) of time rediscovering that, and I'd just like to confirm that that is the case. I'm also wondering whether anyone can point me to where this convention is discussed in the Users Guide or built-in dictionary. Regards, Gregory ___ 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: Naming Custom Properties
I have no issue with this. I remember a while back that single char properties or variables caused a problem. I tested this in a button: on mouseenter put random(99) into xxx set the xxx of me to xxx put the xxx of me end mouseenter gives a bunch of random number whenever you enter the object. Craig Newman ___ 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: Naming Custom Properties
In naming custom props and vars, I try to avoid anything that might 'look' like any function or command name, not starting with a number, and using underscore or dash instead of spaces. However array key names ( myArray[text] ) seem to be able to work against some of these rules (as long as quotes are used). On 16 April 2010 10:24, Gregory Lypny gregory.ly...@videotron.ca wrote: Hello everyone, I vaguely, very vaguely, recall that a custom property should have a name that is different from the variable to which it is being set. So, for example, if myArray is the variable, then set the myPropArray of this stack to myArray is fine, but set the myArray of this stack to myArray does not set anything apparently. I waisted a big chunk (no xTalk pun intended) of time rediscovering that, and I'd just like to confirm that that is the case. I'm also wondering whether anyone can point me to where this convention is discussed in the Users Guide or built-in dictionary. Regards, Gregory - Stephen Barncard Back home in SF ___ 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: Naming Custom Properties
I always use gGlobalVar, vLocalVar, and cpCustomProp just so I know what's what. With these prefixes I never seem to have any conflict. Mark On Apr 16, 2010, at 2:19 PM, stephen barncard wrote: In naming custom props and vars, I try to avoid anything that might 'look' like any function or command name, not starting with a number, and using underscore or dash instead of spaces. However array key names ( myArray[text] ) seem to be able to work against some of these rules (as long as quotes are used). On 16 April 2010 10:24, Gregory Lypny gregory.ly...@videotron.ca wrote: Hello everyone, I vaguely, very vaguely, recall that a custom property should have a name that is different from the variable to which it is being set. So, for example, if myArray is the variable, then set the myPropArray of this stack to myArray is fine, but set the myArray of this stack to myArray does not set anything apparently. I waisted a big chunk (no xTalk pun intended) of time rediscovering that, and I'd just like to confirm that that is the case. I'm also wondering whether anyone can point me to where this convention is discussed in the Users Guide or built-in dictionary. Regards, Gregory - Stephen Barncard Back home in SF ___ 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: Naming Custom Properties
On Apr 16, 2010, at 2:36 PM, Mark Swindell wrote: I always use gGlobalVar, vLocalVar, and cpCustomProp just so I know what's what. With these prefixes I never seem to have any conflict. Mark I agree with Mark about prefixes to avoid reserved word conflicts + debugging at a later date zGlobalStor - sorts to the bottom of Variable Watcher xScriptLocalVar - sorts just above the globals cpCustomPropElement cpsPropertySet arrMusicTrackInfo - array aaaTempVarName - sort to the top of Variable Watcher for debugging As an extra note on this fine Friday afternoon: I name my fields and buttons with a suffix fld nameFld, addressFld, modDateFld btn goNextBtn btn sortByIdBtn, putOutputOnClipbdBtn -- and this helps in the Application Browser Jim Ault Las Vegas On Apr 16, 2010, at 2:36 PM, Mark Swindell wrote: I always use gGlobalVar, vLocalVar, and cpCustomProp just so I know what's what. With these prefixes I never seem to have any conflict. Mark On Apr 16, 2010, at 2:19 PM, stephen barncard wrote: In naming custom props and vars, I try to avoid anything that might 'look' like any function or command name, not starting with a number, and using underscore or dash instead of spaces. However array key names ( myArray[text] ) seem to be able to work against some of these rules (as long as quotes are used). On 16 April 2010 10:24, Gregory Lypny gregory.ly...@videotron.ca wrote: Hello everyone, I vaguely, very vaguely, recall that a custom property should have a name that is different from the variable to which it is being set. So, for example, if myArray is the variable, then set the myPropArray of this stack to myArray is fine, but set the myArray of this stack to myArray does not set anything apparently. I waisted a big chunk (no xTalk pun intended) of time rediscovering that, and I'd just like to confirm that that is the case. I'm also wondering whether anyone can point me to where this convention is discussed in the Users Guide or built-in dictionary. Regards, Gregory ___ 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: Naming Custom Properties
If you note in the Dictionary there is a comment from me on this ``hiccup'' of the custom properties, and it represents a long-standing complaint of mine (i.e., that all custom property names should be quoted literals or the contents of some variable). The problem is this: if variable fred has not been defined, then set the fred of this stack to myArray will, of course create the custom property fred with the contents of myArray. However, if fred has the contents mary then the same line set the fred of this stack to myArray will create the custom property mary with the contents of myArray. And this latter syntax is very convenient for creating custom properties with custom names on the fly. However, to be consistent, the name of the custom property should be a quoted literal when not the contents of a variable name, such that the lines: set the fred of this stack to myArray put fred into mary; set the mary of this stack to myArray do the same thing. The line set the fred of this stack to myArray should throw an error if fred is empty. Unfortunately, nobody at RunRev seems to agree with my desire for a consistent syntax. On 2010-04-16, at 4:51 PM, use-revolution-requ...@lists.runrev.com wrote: Hello everyone, I vaguely, very vaguely, recall that a custom property should have a name that is different from the variable to which it is being set. So, for example, if myArray is the variable, then set the myPropArray of this stack to myArray is fine, but set the myArray of this stack to myArray does not set anything apparently. I waisted a big chunk (no xTalk pun intended) of time rediscovering that, and I'd just like to confirm that that is the case. I'm also wondering whether anyone can point me to where this convention is discussed in the Users Guide or built-in dictionary. Regards, Gregory -- Please avoid sending me Word or PowerPoint attachments. See http://www.gnu.org/philosophy/no-word-attachments.html ___ 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: Naming Custom Properties
On Apr 16, 2010, at 2:06 PM, dunb...@aol.com wrote: I have no issue with this. I remember a while back that single char properties or variables caused a problem. I tested this in a button: on mouseenter put random(99) into xxx set the xxx of me to xxx put the xxx of me end mouseenter gives a bunch of random number whenever you enter the object. Craig Newman Interesting -- I decided to try to get to the bottom of this. I probably haven't gotten to the bottom, but I found out some stuff. If I put the following in the script of button set: on mouseUp put empty into msg put contents 1 into z set the yyy of this card to z set the w of this card to z put prop contents are quote z quote \ into tResult put cr the yyy of this card = (the yyy of this card) \ cr the z of this card = (the z of this card) \ cr after tResult put tResult end mouseup when I click then I get: prop contents are contents 1 the yyy of this card = contents 1 the w of this card = contents 1 Put the following into the script of button get: on mouseUp put the yyy of this card into yyy put the w of this card into zzz put the w of this card into z put yyy = yyy cr after tResult put z = z cr after tResult put zzz = zzz after tResult put tResult after msg end mouseup and you get: yyy = contents 1 z = contents 1 zzz = contents 1 So you *can* usually use single-char prop names to store and retrieve customprops, BUT If you change the top handler to on mouseup put empty into msg put contents 1 into w set the yyy of this card to w set the w of this card to w -- *prop name is same as variable name put prop contents are quote z quote \ into tResult put cr the yyy of this card = (the yyy of this card) \ cr the w of this card = (the w of this card) \ cr after tResult put tResult end mouseup ... and then try to retrieve the property with the get button: put the yyy of this card into yyy put the w of this card into zzz put the w of this card into z you get: yyy = contents 1 z = zzz = So if you set a customprop w to w, it appears empty if you then try to get the prop and put it into a variable. The strange thing is that the engine can interpret the w of this card correctly in put ... the w of this card = (the w of this card)... after tResult in the same handler it was set in. It just can't put the w of this card all by itself into a variable in a separate script. There seems to be a very specific glitch here. Is there a bug report on this? I was unable to find one. It is rather obscure bug but it points to some wrinkle in the engine that should probably be looked at. A stack for exhibiting this behavior is at http://home.comcast.net/~pmbrig/custPropTest.rev.zip -- Peter Peter M. Brigham pmb...@gmail.com http://home.comcast.net/~pmbrig ___ 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: Naming Custom Properties
Thanks for all of the responses! It appears that few of you experience the same problem as me, although everyone has naming conventions that avoid possible name conflicts. One observation, though, with respect to Craig Newman's example. When I call on the custom prop from within the same handler that recreated it, as he does (put the xxx of me), I don't have a problem either. It's when I call on it from without, say, from the message box or a different object with its own script. Regards, Gregory ___ 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: Naming Custom Properties
Vokey, John wrote: However, to be consistent, the name of the custom property should be a quoted literal when not the contents of a variable name Sorry, I disagree with you too. :P Properties, custom or otherwise, aren't quoted. Only literal text strings are quoted. We don't do this: put the rect of btn 1 put the backgroundColor of this stack So we shouldn't do it with custom props either. -- Jacqueline Landman Gay | jac...@hyperactivesw.com 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
Altering custom properties
Is there a simple way of just changing a chunk in a custom property without fetching, changing, and resetting it? For example, let's say I have a custom property cTest that has 1,2,3,4,5,6 in it, and I'd like to make item 3 of cTest *** instead. I can't do either of the following: set item 3 of the cTest of btn foo to *** put *** into item 3 of the cTest of btn foo I know I can do: get the cTest of btn foo put *** into item 3 of it set the cTest of btn foo to it But I'm just hoping there's a nicer shortcut for me to use instead. ;-) Jeff M. ___ 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: Altering custom properties
Hi Jeff, You could create a custom property set with cTest[1] = 1 cTest[2] = 2 cTest[3] = 3 etc. This would allow you to change cTest[3] as follows: set the cTest[3] of me to *** -- Best regards, Mark Schonewille Economy-x-Talk Consulting and Software Engineering Homepage: http://economy-x-talk.com Twitter: http://twitter.com/xtalkprogrammer Economy-x-Talk is always looking for new software development projects. Feel free to contact me for a quote. Op 6 apr 2010, om 19:02 heeft Jeff Massung het volgende geschreven: Is there a simple way of just changing a chunk in a custom property without fetching, changing, and resetting it? For example, let's say I have a custom property cTest that has 1,2,3,4,5,6 in it, and I'd like to make item 3 of cTest *** instead. I can't do either of the following: set item 3 of the cTest of btn foo to *** put *** into item 3 of the cTest of btn foo I know I can do: get the cTest of btn foo put *** into item 3 of it set the cTest of btn foo to it But I'm just hoping there's a nicer shortcut for me to use instead. ;-) Jeff M. ___ 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: Altering custom properties
Jeff. Do you mean can I do this in less than one line of code? Craig Newman ___ 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: Altering custom properties
Well, I'm shooting for less than 3, but less than 1 would be very cool, too. ;-) On Tue, Apr 6, 2010 at 12:39 PM, dunb...@aol.com wrote: Jeff. Do you mean can I do this in less than one line of code? ___ 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: Altering custom properties
Jeff. But you wrote several one-liners yourself. I am missing something. Craig In a message dated 4/6/10 1:55:43 PM, mass...@gmail.com writes: Well, I'm shooting for less than 3, but less than 1 would be very cool, too. ___ 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: Altering custom properties
I wrote several 1-liners that don't compile [as examples of what I'd like to be able to do]. On Tue, Apr 6, 2010 at 12:57 PM, dunb...@aol.com wrote: Jeff. But you wrote several one-liners yourself. I am missing something. ___ 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: Altering custom properties
Jeff Massung wrote: Well, I'm shooting for less than 3, but less than 1 would be very cool, too. ;-) Well, this: on mouseup end mouseup It's less than one line of code, although I admit it doen't do much. :) For your original question, no, there's no shorter way to do it. You have to get, change, set the property. The only way to make it a semi-one-liner is to write a custom function that does all that, and then just call your function. -- Jacqueline Landman Gay | jac...@hyperactivesw.com 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: Altering custom properties
Jeff, What's wrong with the solution I proposed? -- Best regards, Mark Schonewille Economy-x-Talk Consulting and Software Engineering Homepage: http://economy-x-talk.com Twitter: http://twitter.com/xtalkprogrammer Economy-x-Talk is always looking for new software development projects. Feel free to contact me for a quote. Op 6 apr 2010, om 20:02 heeft Jeff Massung het volgende geschreven: I wrote several 1-liners that don't compile [as examples of what I'd like to be able to do]. On Tue, Apr 6, 2010 at 12:57 PM, dunb...@aol.com wrote: Jeff. But you wrote several one-liners yourself. I am missing something. ___ 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: Altering custom properties
Jeff: Ah. Forgot about that, and I had a heated discussion with someone on the HC list decades ago about this very thing. You cannot set chunks of a property, even a built-in one. He wanted to be able to change the script of an object in just the way you want to change a custom property (he had a self modifying code need). He wanted to put something into line 39 or whatever of the script of an object. I explained that scripts were properties, not containers. You had to put the whole property into a container first, then fool around with it, then set. We worked it out. Maybe this could be a feature request? Unless there is something about the way the engine treats properties, like HC, that precludes it. Craig ___ 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: Altering custom properties
Mark. Too long. Craig In a message dated 4/6/10 2:07:22 PM, m.schonewi...@economy-x-talk.com writes: What's wrong with the solution I proposed? ___ 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: Altering custom properties
On Tue, Apr 6, 2010 at 1:07 PM, Mark Schonewille m.schonewi...@economy-x-talk.com wrote: Jeff, What's wrong with the solution I proposed? Nothing at all. In fact, I ended up doing something similar based on your idea and it worked great. ;-) Jeff M. ___ 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
Custom Properties
Hi All, I'm looking for a lesson, where I can load or import files such as swf, css, js and html into Rev. I believe that one must set the Custom Properties to handle these files, but have not found a way to do such. Once I have them in Rev, I can use the SpecialFolders path to push them out to a temporary folder. I've been playing with the Special Folders Utility.rev and browser_sampler.rev and am able to load these files into the revBrowser, after having manualy put them into a Special Folder like: C:/Users/William/AppData/Local/Temp/10.4/ Best, William William Roger Moseid b...@fmpsolutions.com __ Information from ESET Smart Security, version of virus signature database 4953 (20100317) __ The message was checked by ESET Smart Security. http://www.eset.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: Custom Properties
William- answer file wo ist du? if it is not empty then set the uSavedFile of this stack to url (file: it) end if -- -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: FYI: writing to and reading from fields much faster than locals, globals or custom properties
On Feb 19, 2010, at 8:52 PM, Jim Bufalini wrote: Josh Mellicker wrote: Oops. I learned coding from an old guy in an alley, that's why. :-) When a handler is not event driven, but just looping, monitoring something, and keeps calling itself, what is the proper term? Recursion or recursive. This is the same as a tight loop because the handler never ends until the recursive calling stops. Hence, without waits *with messages* you will have a sluggish GUI. Just FYI, we were using: if monitorExternalProcess is not in the pendingMessages then send monitorExternalProcess to me in 1 milliseconds That's why I was calling it a 1 millisecond loop. Since this only calls itself once at a time, it's not recursive, right? Also, you could easily hit the recursive limit if the condition you are looking for does not occur as you expect, and your program will crash. Use instead: send thisHandlerName to me in 1 millisecond This will solve all of your problems of allowing the GUI to be responsive and avoid hitting the recursion limit. One thing to be aware of though, in any case, of using *wait... with messages* or sending in time. The time factor is not absolute. If, for example, a handler that takes 10 milliseconds to execute is triggered then there will be 10 milliseconds between executions of your in-time loops Aloha from Hawaii, Jim Bufalini ___ 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: FYI: writing to and reading from fields much faster than locals, globals or custom properties
On Feb 17, 2010, at 10:02 PM, Jan Schenkel wrote: --- On Wed, 2/17/10, Josh Mellicker j...@dvcreators.net wrote: You all probably know this, but thought I would share our experience anyway: We are working on a project with a 1 millisecond callback loop that communicates with an external process in a performance-critical application, and when prototyping, temporarily used some fields on a card to write and read values from during the loop. Then, while buttoning things up, instead of fields, we switched to reading and writing a custom property. Suddenly, everything went sluggish - you had to click on a button several times to trigger it, you could barely move stack windows, etc. It took a while to figure out the culprit, but once we went line by line from our original prototype script, wee found that going back to reading and writing to a field made everything work smoothly again! Then we tried local, then a global variable... not good... same result as custom properties. So if you are writing an app where performance is critical, Rev reads and writes to fields super fast! If the field you're using to set/get data, is _invisible_ then it makes sense that this would be faster than set/get data using a custom property: built-in properties don't have to traverse the message hierarchy for setProp/getProp handlers, and an invisible field doesn't have to redraw itself. Why it would be faster than global/local variable access, is a puzzler - are you using arrays or storing the text in the same 'flat' way as field text? I never tried arrays, just global, local, custom property and a text field. Jan Schenkel = Quartam Reports PDF Library for Revolution http://www.quartam.com = As we grow older, we grow both wiser and more foolish at the same time. (La Rochefoucauld) ___ 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: FYI: writing to and reading from fields much faster than locals, globals or custom properties
On Feb 17, 2010, at 10:44 PM, Jim Ault wrote: On Feb 17, 2010, at 8:10 PM, Josh Mellicker wrote: You all probably know this, but thought I would share our experience anyway: We are working on a project with a 1 millisecond callback loop that communicates with an external process in a performance-critical application, and when prototyping, temporarily used some fields on a card to write and read values from during the loop. Then, while buttoning things up, instead of fields, we switched to reading and writing a custom property. Suddenly, everything went sluggish - you had to click on a button several times to trigger it, you could barely move stack windows, etc. It took a while to figure out the culprit, but once we went line by line from our original prototype script, wee found that going back to reading and writing to a field made everything work smoothly again! Then we tried local, then a global variable... not good... same result as custom properties. So if you are writing an app where performance is critical, Rev reads and writes to fields super fast!___ Something does not seem to be correct in this instance. I know, I've always had the impression fields were slower. Which version of Rev? Which platform? The latest, Mac 10.6.2 Is the flag script debug mode set to false? no Are there any pending messages in the queue? The callback handler calls itself: if monitorExternalProcess is not in the pendingMessages then send monitorExternalProcess to me in 1 milliseconds Front scripts? back scripts? no I have done many performance-critical event loops using variables and custom properties in networking apps between computers and offices. Whenever I encounter a slow down, I look at my error trapping loops or status detection code and find that I have added clock cycles by not programming properly. If you have discovered something that affects the performance so that fields are noticeably faster, then we need to know what is happening. I have never tested fields to be as fast or faster than custom properties, especially for larger blocks of text (such as whole web page HTML) Please, when you have time, provide a little more feedback. I will, we need to get this revision out the door, then I will try and do some more tests. 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 ___ 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: FYI: writing to and reading from fields much faster than locals, globals or custom properties
On Feb 18, 2010, at 4:29 PM, Kay C Lan wrote: On Fri, Feb 19, 2010 at 3:21 AM, Richard Gaskin ambassa...@fourthworld.com wrote: Maybe that should be Benchmark Obsessive. :) True, I was sleeping at 1AM PST, but when I got up this morning I found this intriguing enough to pull out one of my old test stacks. In fact, while I was at it I took some notes for an article on benchmarking I've been itching to write and posted it to revJournal: Hmmm, maybe 'Benchmark Obsessive Compulsive' ;-) Using Richard's stack: MBP 17 2.16 GHz, 2GB RAM OS X.6.2, Rev 4.0.0 Build 950 Number of iterations for read/write access: 5000 LockScreen = true LockMessages = true Results: Visible field, current card: 24 Hidden field, current card: 22 Visible field, unopened card: 13 Hidden field, unopened card: 14 Custom property: 4 Global variable: 2 Local variable: 1 Number of iterations for read/write access: 5000 LockScreen = false LockMessages = false Results: Visible field, current card: 2367 Hidden field, current card: 2856 Visible field, unopened card: 15 Hidden field, unopened card: 14 Custom property: 37 Global variable: 2 Local variable: 1 So very similar results. Josh, we are waiting ??? Just to reiterate: What we found was that when writing and reading a custom property, or a variable, in a 1 ms loop, other stack windows became sluggish - very difficult to drag by the header bar, very difficult to click buttons on, rollover states sticking. When we replaced with writing to and reading a text field on a substack (still 1ms), the other windows responded perfectly normally, you could drag and click just like no callback loop was running. So I just ASSUMED the field was faster. Maybe the truth is that custom properties , although faster, somehow interfere with normal mouse-related processes... or maybe what we found was just specific to our app, although I don't see how that could be. Anyway, I will do some more tests as soon as I can. I just wanted to post, in case someone noticed sluggishness in an app with a fast callback loop, my advice is, try fields and see if that fixes it - it did for us! ___ 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: FYI: writing to and reading from fields much faster than locals, globals or custom properties
Recently, Josh Mellicker wrote: What we found was that when writing and reading a custom property, or a variable, in a 1 ms loop, other stack windows became sluggish - very difficult to drag by the header bar, very difficult to click buttons on, rollover states sticking. When we replaced with writing to and reading a text field on a substack (still 1ms), the other windows responded perfectly normally, you could drag and click just like no callback loop was running. So I just ASSUMED the field was faster. Maybe the truth is that custom properties , although faster, somehow interfere with normal mouse-related processes... or maybe what we found was just specific to our app, although I don't see how that could be. Anyway, I will do some more tests as soon as I can. I just wanted to post, in case someone noticed sluggishness in an app with a fast callback loop, my advice is, try fields and see if that fixes it - it did for us! Do you have any custom drag routines in your stack/s? Do you update any kind of output while the loop is running? My guess is your repeat loop is so tight that the writing to the field causes a screen update which slows the repeat loop and allows other events such as window dragging to take place. In my experience, a repeat loop will only usually down events when updating the screen repeatedly. You should also fit some lock/unlock screen into your testing to see how that affects your loop/s and processing speed. Regards, Scott Rossi Creative Director Tactile Media, UX Design ___ 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: FYI: writing to and reading from fields much faster than locals, globals or custom properties
Josh Mellicker wrote: What we found was that when writing and reading a custom property, or a variable, in a 1 ms loop, other stack windows became sluggish - very difficult to drag by the header bar, very difficult to click buttons on, rollover states sticking. Ahhh...Now THIS makes sense. Your repeat loop is so tight that the GUI becomes unresponsive. It has nothing to do with the actual speed of variables vs. fields. Please add, somewhere in your repeat loop: wait 0 milliseconds with messages When we replaced with writing to and reading a text field on a substack (still 1ms), the other windows responded perfectly normally, you could drag and click just like no callback loop was running. Yes, because here other handlers are starting and stopping and this gives the engine opportunity to intervene. So I just ASSUMED the field was faster. Maybe the truth is that custom properties , although faster, somehow interfere with normal mouse-related processes... or maybe what we found was just specific to our app, although I don't see how that could be. It's the repeat loop itself without any wait or other handlers being called. Anyway, I will do some more tests as soon as I can. I just wanted to post, in case someone noticed sluggishness in an app with a fast callback loop, my advice is, try fields and see if that fixes it - it did for us! Just add the wait into your repeat loop with vars or custom props and you will see it is even faster than fields. ;-) Aloha from Hawaii, Jim Bufalini ___ 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: FYI: writing to and reading from fields much faster than locals, globals or custom properties
Jim Bufalini wrote: Josh Mellicker wrote: What we found was that when writing and reading a custom property, or a variable, in a 1 ms loop, other stack windows became sluggish - very difficult to drag by the header bar, very difficult to click buttons on, rollover states sticking. Ahhh...Now THIS makes sense. Your repeat loop is so tight that the GUI becomes unresponsive. It has nothing to do with the actual speed of variables vs. fields. Please add, somewhere in your repeat loop: wait 0 milliseconds with messages Exactly what I was thinking. I believe you've nailed it. -- Jacqueline Landman Gay | jac...@hyperactivesw.com 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: FYI: writing to and reading from fields much faster than locals, globals or custom properties
BTW, it's the *with messages* that is important. Also, your use of *callback loop* is interesting. A callback is a handler that is triggered when a callback event occurs, much like a mouseUp handler is triggered on a mouseUp event. It's never in a repeat loop. Aloha from Hawaii, Jim Bufalini -Original Message- From: use-revolution-boun...@lists.runrev.com [mailto:use-revolution- boun...@lists.runrev.com] On Behalf Of Jim Bufalini Sent: Friday, February 19, 2010 4:56 PM To: 'How to use Revolution' Subject: RE: FYI: writing to and reading from fields much faster than locals, globals or custom properties Josh Mellicker wrote: What we found was that when writing and reading a custom property, or a variable, in a 1 ms loop, other stack windows became sluggish - very difficult to drag by the header bar, very difficult to click buttons on, rollover states sticking. Ahhh...Now THIS makes sense. Your repeat loop is so tight that the GUI becomes unresponsive. It has nothing to do with the actual speed of variables vs. fields. Please add, somewhere in your repeat loop: wait 0 milliseconds with messages When we replaced with writing to and reading a text field on a substack (still 1ms), the other windows responded perfectly normally, you could drag and click just like no callback loop was running. Yes, because here other handlers are starting and stopping and this gives the engine opportunity to intervene. So I just ASSUMED the field was faster. Maybe the truth is that custom properties , although faster, somehow interfere with normal mouse-related processes... or maybe what we found was just specific to our app, although I don't see how that could be. It's the repeat loop itself without any wait or other handlers being called. Anyway, I will do some more tests as soon as I can. I just wanted to post, in case someone noticed sluggishness in an app with a fast callback loop, my advice is, try fields and see if that fixes it - it did for us! Just add the wait into your repeat loop with vars or custom props and you will see it is even faster than fields. ;-) Aloha from Hawaii, Jim Bufalini ___ 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: FYI: writing to and reading from fields much faster than locals, globals or custom properties
You should also fit some lock/unlock screen into your testing to see how that affects your loop/s and processing speed. Will do, thanks Scott! On Feb 19, 2010, at 6:35 PM, Scott Rossi wrote: Recently, Josh Mellicker wrote: What we found was that when writing and reading a custom property, or a variable, in a 1 ms loop, other stack windows became sluggish - very difficult to drag by the header bar, very difficult to click buttons on, rollover states sticking. When we replaced with writing to and reading a text field on a substack (still 1ms), the other windows responded perfectly normally, you could drag and click just like no callback loop was running. So I just ASSUMED the field was faster. Maybe the truth is that custom properties , although faster, somehow interfere with normal mouse-related processes... or maybe what we found was just specific to our app, although I don't see how that could be. Anyway, I will do some more tests as soon as I can. I just wanted to post, in case someone noticed sluggishness in an app with a fast callback loop, my advice is, try fields and see if that fixes it - it did for us! Do you have any custom drag routines in your stack/s? Do you update any kind of output while the loop is running? My guess is your repeat loop is so tight that the writing to the field causes a screen update which slows the repeat loop and allows other events such as window dragging to take place. In my experience, a repeat loop will only usually down events when updating the screen repeatedly. You should also fit some lock/unlock screen into your testing to see how that affects your loop/s and processing speed. Regards, Scott Rossi Creative Director Tactile Media, UX Design ___ 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: FYI: writing to and reading from fields much faster than locals, globals or custom properties
Just add the wait into your repeat loop with vars or custom props and you will see it is even faster than fields. ;-) Will do! Thanks Jim, your message cleared some some things! On Feb 19, 2010, at 6:55 PM, Jim Bufalini wrote: Josh Mellicker wrote: What we found was that when writing and reading a custom property, or a variable, in a 1 ms loop, other stack windows became sluggish - very difficult to drag by the header bar, very difficult to click buttons on, rollover states sticking. Ahhh...Now THIS makes sense. Your repeat loop is so tight that the GUI becomes unresponsive. It has nothing to do with the actual speed of variables vs. fields. Please add, somewhere in your repeat loop: wait 0 milliseconds with messages When we replaced with writing to and reading a text field on a substack (still 1ms), the other windows responded perfectly normally, you could drag and click just like no callback loop was running. Yes, because here other handlers are starting and stopping and this gives the engine opportunity to intervene. So I just ASSUMED the field was faster. Maybe the truth is that custom properties , although faster, somehow interfere with normal mouse-related processes... or maybe what we found was just specific to our app, although I don't see how that could be. It's the repeat loop itself without any wait or other handlers being called. Anyway, I will do some more tests as soon as I can. I just wanted to post, in case someone noticed sluggishness in an app with a fast callback loop, my advice is, try fields and see if that fixes it - it did for us! Just add the wait into your repeat loop with vars or custom props and you will see it is even faster than fields. ;-) Aloha from Hawaii, Jim Bufalini ___ 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: FYI: writing to and reading from fields much faster than locals, globals or custom properties
Oops. I learned coding from an old guy in an alley, that's why. :-) When a handler is not event driven, but just looping, monitoring something, and keeps calling itself, what is the proper term? On Feb 19, 2010, at 7:20 PM, Jim Bufalini wrote: BTW, it's the *with messages* that is important. Also, your use of *callback loop* is interesting. A callback is a handler that is triggered when a callback event occurs, much like a mouseUp handler is triggered on a mouseUp event. It's never in a repeat loop. Aloha from Hawaii, Jim Bufalini -Original Message- From: use-revolution-boun...@lists.runrev.com [mailto:use-revolution- boun...@lists.runrev.com] On Behalf Of Jim Bufalini Sent: Friday, February 19, 2010 4:56 PM To: 'How to use Revolution' Subject: RE: FYI: writing to and reading from fields much faster than locals, globals or custom properties Josh Mellicker wrote: What we found was that when writing and reading a custom property, or a variable, in a 1 ms loop, other stack windows became sluggish - very difficult to drag by the header bar, very difficult to click buttons on, rollover states sticking. Ahhh...Now THIS makes sense. Your repeat loop is so tight that the GUI becomes unresponsive. It has nothing to do with the actual speed of variables vs. fields. Please add, somewhere in your repeat loop: wait 0 milliseconds with messages When we replaced with writing to and reading a text field on a substack (still 1ms), the other windows responded perfectly normally, you could drag and click just like no callback loop was running. Yes, because here other handlers are starting and stopping and this gives the engine opportunity to intervene. So I just ASSUMED the field was faster. Maybe the truth is that custom properties , although faster, somehow interfere with normal mouse-related processes... or maybe what we found was just specific to our app, although I don't see how that could be. It's the repeat loop itself without any wait or other handlers being called. Anyway, I will do some more tests as soon as I can. I just wanted to post, in case someone noticed sluggishness in an app with a fast callback loop, my advice is, try fields and see if that fixes it - it did for us! Just add the wait into your repeat loop with vars or custom props and you will see it is even faster than fields. ;-) Aloha from Hawaii, Jim Bufalini ___ 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 ___ 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: FYI: writing to and reading from fields much faster than locals, globals or custom properties
Josh Mellicker wrote: Oops. I learned coding from an old guy in an alley, that's why. :-) When a handler is not event driven, but just looping, monitoring something, and keeps calling itself, what is the proper term? Recursion or recursive. This is the same as a tight loop because the handler never ends until the recursive calling stops. Hence, without waits *with messages* you will have a sluggish GUI. Also, you could easily hit the recursive limit if the condition you are looking for does not occur as you expect, and your program will crash. Use instead: send thisHandlerName to me in 1 millisecond This will solve all of your problems of allowing the GUI to be responsive and avoid hitting the recursion limit. One thing to be aware of though, in any case, of using *wait... with messages* or sending in time. The time factor is not absolute. If, for example, a handler that takes 10 milliseconds to execute is triggered then there will be 10 milliseconds between executions of your in-time loops Aloha from Hawaii, Jim Bufalini ___ 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: FYI: writing to and reading from fields much faster than locals, globals or custom properties
On Feb 17, 2010, at 8:10 PM, Josh Mellicker wrote: Rev reads and writes to fields super fast! Clearly Richard 'the Benchmark King' Gaskin is asleep right now, but when he wakes I'm sure he'll have the figures. The best I could track down was some benchmarking Richard did a while back comparing Globals, Custom Property's and Functions. His test was a simple one liner repeated 1 million times, the results were (in milliseconds): Global: 0.00023 Property: 0.00151 Function: 0.00198 So whilst it is good to know that Rev can read and write into fields in under a 1 millisecond, and you may consider that super fast, NORMALLY using Globals or Custom Properties will result in a speed increase of several orders of magnitude. Obviously you are not experiencing normal so many of us here would be very interested in more details to understand why. And if I were a betting man, I'd be putting my money on the end result will be using Globals will be the fastest option for you. ___ 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: writing to and reading from fields much faster than locals, globals or custom properties
Josh Mellicker wrote: You all probably know this, but thought I would share our experience anyway: We are working on a project with a 1 millisecond callback loop that communicates with an external process in a performance-critical application, and when prototyping, temporarily used some fields on a card to write and read values from during the loop. Then, while buttoning things up, instead of fields, we switched to reading and writing a custom property. Suddenly, everything went sluggish - you had to click on a button several times to trigger it, you could barely move stack windows, etc. It took a while to figure out the culprit, but once we went line by line from our original prototype script, wee found that going back to reading and writing to a field made everything work smoothly again! Then we tried local, then a global variable... not good... same result as custom properties. So if you are writing an app where performance is critical, Rev reads and writes to fields super fast Josh, What we know is actually quite the opposite. The speed order should be local/global/constant - custom property - field, with a very miniscule difference between globals and custom properties (custom props have to be copied in memory first) and a very significant difference between any of these and fields, even with *lock screen*. Would you be so kind as to isolate and confirm your results and let us know which Rev and on what platform/OS and provide us with a code example or, better yet, a test stack we can download that demonstrates what you are experiencing, so we can all test your code on different platforms and versions of Rev for ourselves? If you are running a recent release of Rev and what you are saying proves to be so for that release, then you have discovered a major bug. So, it's very important! Thanks! Aloha from Hawaii, Jim Bufalini ___ 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: FYI: writing to and reading from fields much faster than locals, globals or custom properties
Kay C Lan wrote: Obviously you are not experiencing normal so many of us here would be very interested in more details to understand why. And if I were a betting man, I'd be putting my money on the end result will be using Globals will be the fastest option for you. Agreed. Dr. Raney once told me speed was in this order: global variables local variables custom properties fields So I too would like to know what the situation is where fields could possibly be faster than the other options. If the field is hidden or the IDE is not running (i.e., a CGI,) I might be able to see that fields could be as fast as custom properties since most of the overhead of writing to fields involves the drawing routines. But it shouldn't be faster than variables. -- Jacqueline Landman Gay | jac...@hyperactivesw.com 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: FYI: writing to and reading from fields much faster than locals, globals or custom properties
J. Landman Gay wrote: Dr. Raney once told me speed was in this order: global variables local variables custom properties fields I should amend that. I'm not positive about the order of the first two. I might have them reversed. What I am sure about is that variables are faster than properties, which are faster than fields. -- Jacqueline Landman Gay | jac...@hyperactivesw.com 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: FYI: writing to and reading from fields much faster than locals, globals or custom properties
It must be the first mistake you make when writing your first Rev program - at least, it was mine. On an old used donated celeron, I had written a script that went through several thousands of lines and extracted sub totals from tab delimited fields. As the file increased in size, the computation slowed down. I was of course doing it in fields. Finally when it was starting to take minutes, I put in a button that said 'just look at the report, don't redo it'! The things we think of! In the end, I discovered that you should sum the subtotals into variables and then put the variables into the fields, and it became almost instant. So this seems like a very easy thing to test, just generate 20k lines of numbers and do some totals into fields and also alternatively into a variable and then put into the same fields. The difference in my experience on a slow machine was, literally, a matter of minutes. -- View this message in context: http://n4.nabble.com/FYI-writing-to-and-reading-from-fields-much-faster-than-locals-globals-or-custom-properties-tp1559633p1560686.html Sent from the Revolution - User mailing list archive at Nabble.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: FYI: writing to and reading from fields much faster than locals, globals or custom properties
At 03:09:01 CST 2010 Kay C Lan wrote: On Feb 17, 2010, at 8:10 PM, Josh Mellicker wrote: Rev reads and writes to fields super fast! Clearly Richard 'the Benchmark King' Gaskin is asleep right now, but when he wakes I'm sure he'll have the figures. Maybe that should be Benchmark Obsessive. :) True, I was sleeping at 1AM PST, but when I got up this morning I found this intriguing enough to pull out one of my old test stacks. In fact, while I was at it I took some notes for an article on benchmarking I've been itching to write and posted it to revJournal: Benchmarking Performance in RevTalk http://www.revjournal.com/tutorials/benchmarking-revtalk.html Using this exercise of data access as an example, the code, results, and downloadable stack are in this section: http://www.revjournal.com/tutorials/benchmarking-revtalk.html#example The bottom line in my tests reflect Dr. Raney's comments that Jacque noted: Number of iterations for read/write access: 5000 LockScreen = true LockMessages = true Results: Visible field, current card: 22 Hidden field, current card: 23 Visible field, unopened card: 13 Hidden field, unopened card: 14 Custom property: 5 Global variable: 1 Local variable: 2 Number of iterations for read/write access: 5000 LockScreen = false LockMessages = false Results: Visible field, current card: 3353 Hidden field, current card: 4823 Visible field, unopened card: 13 Hidden field, unopened card: 14 Custom property: 13 Global variable: 2 Local variable: 1 One of the challenges in attempting to determine performance within a complex system is that there's so much going on that can affect things. Benchmarking specific elements in isolation removes most of those interactions, usually leading to more repeatable results. -- Richard Gaskin Fourth World Rev training and consulting: http://www.fourthworld.com Webzine for Rev developers: http://www.revjournal.com revJournal blog: http://revjournal.com/blog.irv ___ 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: FYI: writing to and reading from fields much faster than locals, globals or custom properties
On Fri, Feb 19, 2010 at 3:21 AM, Richard Gaskin ambassa...@fourthworld.com wrote: Maybe that should be Benchmark Obsessive. :) True, I was sleeping at 1AM PST, but when I got up this morning I found this intriguing enough to pull out one of my old test stacks. In fact, while I was at it I took some notes for an article on benchmarking I've been itching to write and posted it to revJournal: Hmmm, maybe 'Benchmark Obsessive Compulsive' ;-) Using Richard's stack: MBP 17 2.16 GHz, 2GB RAM OS X.6.2, Rev 4.0.0 Build 950 Number of iterations for read/write access: 5000 LockScreen = true LockMessages = true Results: Visible field, current card:24 Hidden field, current card: 22 Visible field, unopened card: 13 Hidden field, unopened card:14 Custom property:4 Global variable:2 Local variable: 1 Number of iterations for read/write access: 5000 LockScreen = false LockMessages = false Results: Visible field, current card:2367 Hidden field, current card: 2856 Visible field, unopened card: 15 Hidden field, unopened card:14 Custom property:37 Global variable:2 Local variable: 1 So very similar results. Josh, we are waiting ??? ___ 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: FYI: writing to and reading from fields much faster than locals, globals or custom properties
On Thu, Feb 18, 2010 at 12:10 PM, Josh Mellicker j...@dvcreators.net wrote: Then, while buttoning things up, instead of fields, we switched to reading and writing a custom property. Suddenly, everything went sluggish - you had to click on a button several times to trigger it, you could barely move stack windows, etc. Actually, using Richard's benchmark stack, I consistently get customProperties slower than fields if the LockMessages is false and the LockScreen is true. MBP 17 2.16 GHz, 2GB RAM OS X.6.2, Rev 4.0.0 Build 950 Number of iterations for read/write access: 5000 LockScreen = true LockMessages = false Results: Visible field, current card:23 Hidden field, current card: 22 Visible field, unopened card: 14 Hidden field, unopened card:14 Custom property:37 Global variable:2 Local variable: 1 If Josh was using such a set-up, with fields on an unopened card, that's a significant performance hit to move to customProperties. ___ 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: custom properties
Kay C Lan wrote: On Thu, Feb 18, 2010 at 12:10 PM, Josh Mellicker wrote: Then, while buttoning things up, instead of fields, we switched to reading and writing a custom property. Suddenly, everything went sluggish - you had to click on a button several times to trigger it, you could barely move stack windows, etc. Actually, using Richard's benchmark stack, I consistently get customProperties slower than fields if the LockMessages is false and the LockScreen is true. MBP 17 2.16 GHz, 2GB RAM OS X.6.2, Rev 4.0.0 Build 950 Number of iterations for read/write access: 5000 LockScreen = true LockMessages = false Results: Visible field, current card: 23 Hidden field, current card:22 Visible field, unopened card: 14 Hidden field, unopened card: 14 Custom property: 37 Global variable: 2 Local variable:1 If Josh was using such a set-up, with fields on an unopened card, that's a significant performance hit to move to customProperties. While his description suggests a difference greater than we see in your results, I think you may have stumbled across a useful distinction here: When I wrote this I was unable to get the results you posted, but since your system config is very similar to mine and our other results were almost exact matches, I figured the must be a way for me to be able to reproduce your results. Then I figured it out: You're not running my custom IDE. :) In my IDE, forked from MC, it follows MC's tradition of lean message handling; it's a very close match to the runtime environment, more closely matching behavior of standalones. In contrast, Rev's IDE has a number of setProp and getProp handlers in its front and backscripts. Once I ran my test in the Rev IDE I was able to get results like yours with those settings. Since everything else is the same except for the getProp and setProp handlers elsewhere in the environment, there would seem to be a relationship between the number of such handlers in the message path and the performance of property accesses, even for properties completely unrelated to those handled by the getProp and setProp handlers (looks like an opportunity for optimization). I haven't tried this out yet, but I wonder if one had a setProp/getProp-rich message path whether it would slow down performance as much as described. But even then, none of this explains how variables could appear slower. -- Richard Gaskin Fourth World Rev training and consulting: http://www.fourthworld.com Webzine for Rev developers: http://www.revjournal.com revJournal blog: http://revjournal.com/blog.irv ___ 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
FYI: writing to and reading from fields much faster than locals, globals or custom properties
You all probably know this, but thought I would share our experience anyway: We are working on a project with a 1 millisecond callback loop that communicates with an external process in a performance-critical application, and when prototyping, temporarily used some fields on a card to write and read values from during the loop. Then, while buttoning things up, instead of fields, we switched to reading and writing a custom property. Suddenly, everything went sluggish - you had to click on a button several times to trigger it, you could barely move stack windows, etc. It took a while to figure out the culprit, but once we went line by line from our original prototype script, wee found that going back to reading and writing to a field made everything work smoothly again! Then we tried local, then a global variable... not good... same result as custom properties. So if you are writing an app where performance is critical, Rev reads and writes to fields super fast!___ 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: FYI: writing to and reading from fields much faster than locals, globals or custom properties
That is counter to what we've been taught was the case previously. In previous versions the field overhead was far greater than CPs. Perhaps it's the multi-dimensional aspect. - Stephen Barncard San Francisco http://houseofcubes.com/disco.irev On 17 February 2010 20:10, Josh Mellicker j...@dvcreators.net wrote: You all probably know this, but thought I would share our experience anyway: We are working on a project with a 1 millisecond callback loop that communicates with an external process in a performance-critical application, and when prototyping, temporarily used some fields on a card to write and read values from during the loop. Then, while buttoning things up, instead of fields, we switched to reading and writing a custom property. Suddenly, everything went sluggish - you had to click on a button several times to trigger it, you could barely move stack windows, etc. It took a while to figure out the culprit, but once we went line by line from our original prototype script, wee found that going back to reading and writing to a field made everything work smoothly again! Then we tried local, then a global variable... not good... same result as custom properties. So if you are writing an app where performance is critical, Rev reads and writes to fields super fast!___ 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: FYI: writing to and reading from fields much faster than locals, globals or custom properties
--- On Wed, 2/17/10, Josh Mellicker j...@dvcreators.net wrote: You all probably know this, but thought I would share our experience anyway: We are working on a project with a 1 millisecond callback loop that communicates with an external process in a performance-critical application, and when prototyping, temporarily used some fields on a card to write and read values from during the loop. Then, while buttoning things up, instead of fields, we switched to reading and writing a custom property. Suddenly, everything went sluggish - you had to click on a button several times to trigger it, you could barely move stack windows, etc. It took a while to figure out the culprit, but once we went line by line from our original prototype script, wee found that going back to reading and writing to a field made everything work smoothly again! Then we tried local, then a global variable... not good... same result as custom properties. So if you are writing an app where performance is critical, Rev reads and writes to fields super fast! If the field you're using to set/get data, is _invisible_ then it makes sense that this would be faster than set/get data using a custom property: built-in properties don't have to traverse the message hierarchy for setProp/getProp handlers, and an invisible field doesn't have to redraw itself. Why it would be faster than global/local variable access, is a puzzler - are you using arrays or storing the text in the same 'flat' way as field text? Jan Schenkel = Quartam Reports PDF Library for Revolution http://www.quartam.com = As we grow older, we grow both wiser and more foolish at the same time. (La Rochefoucauld) ___ 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: FYI: writing to and reading from fields much faster than locals, globals or custom properties
On Feb 17, 2010, at 8:10 PM, Josh Mellicker wrote: You all probably know this, but thought I would share our experience anyway: We are working on a project with a 1 millisecond callback loop that communicates with an external process in a performance-critical application, and when prototyping, temporarily used some fields on a card to write and read values from during the loop. Then, while buttoning things up, instead of fields, we switched to reading and writing a custom property. Suddenly, everything went sluggish - you had to click on a button several times to trigger it, you could barely move stack windows, etc. It took a while to figure out the culprit, but once we went line by line from our original prototype script, wee found that going back to reading and writing to a field made everything work smoothly again! Then we tried local, then a global variable... not good... same result as custom properties. So if you are writing an app where performance is critical, Rev reads and writes to fields super fast! ___ Something does not seem to be correct in this instance. Which version of Rev? Which platform? Is the flag script debug mode set to false? Are there any pending messages in the queue? Front scripts? back scripts? I have done many performance-critical event loops using variables and custom properties in networking apps between computers and offices. Whenever I encounter a slow down, I look at my error trapping loops or status detection code and find that I have added clock cycles by not programming properly. If you have discovered something that affects the performance so that fields are noticeably faster, then we need to know what is happening. I have never tested fields to be as fast or faster than custom properties, especially for larger blocks of text (such as whole web page HTML) Please, when you have time, provide a little more feedback. 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
Deleting Custom Properties
Hi All, I've been playing with custom properties over the past several weeks for pretty much the first time. I've been able to create, fill, and empty them via script... however, I've not been to delete one via script. How is that accomplished? take care, randy hengst ___ 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: Deleting Custom Properties
You have to do it in steps: 1- Put all the custom property names of the object in, say, separate lines of a variable. 2- Delete the line containing the property in question from that variable. 3- Set the customkeys of the object to the (newly modified) variable. I don't know why you cannot just delete the customProp as easily as you create them. Craig Newman ** Shop Popular Dell Laptops now starting at $349! (http://pr.atwola.com/promoclk/100126575x1222031056x1201446063/aol?redir=http: %2F%2Fad.doubleclick.net%2Fclk%3B215910283%3B38350812%3Ba) ___ 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: Deleting Custom Properties
Hi Randy, Hi All, I've been playing with custom properties over the past several weeks for pretty much the first time. I've been able to create, fill, and empty them via script... however, I've not been to delete one via script. How is that accomplished? this is the most cumbersome thingie in the whole Rev universe :-D Fact is, you have to: ... put the customkeys of btn xyz into cp_list put lineoffset(propname_to_delete,cp_list) into line_nr delete line line_nr of cp_list set the customkeys of btn xyz to cp_list ... BTW, has this ever bee bugzilla'd as an enhancement? take care, randy hengst Best Klaus -- Klaus Major http://www.major-k.de kl...@major.on-rev.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: Deleting Custom Properties
I should have mentioned that the way to put all the custom props into a variable is to: put the customKeys of yourObject into yourVariable This is in the user guide under Deleting a custom property. It should be native, but at least can be written and kept as a utility handler in your toolbox. Craig Newman ** Shop Popular Dell Laptops now starting at $349! (http://pr.atwola.com/promoclk/100126575x1222031056x1201446063/aol?redir=http: %2F%2Fad.doubleclick.net%2Fclk%3B215910283%3B38350812%3Ba) ___ 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: Deleting Custom Properties
Thank you Craig and Klaus... Deleting custom properties feels quite cumbersome when compared to creating and using them. I'm not sure how I missed the info in the User Guide... take care randy - On Jun 25, 2009, at 1:50 PM, dunb...@aol.com wrote: I should have mentioned that the way to put all the custom props into a variable is to: put the customKeys of yourObject into yourVariable This is in the user guide under Deleting a custom property. It should be native, but at least can be written and kept as a utility handler in your toolbox. Craig Newman ** Shop Popular Dell Laptops now starting at $349! (http://pr.atwola.com/promoclk/100126575x1222031056x1201446063/aol? redir=http: %2F%2Fad.doubleclick.net%2Fclk%3B215910283%3B38350812%3Ba) ___ 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: Deleting Custom Properties
Klaus, a slightly simpler way is to use the fact the the customproperties of an object is an array, so: put the customproperties of btn xyz into tArray delete variable tArray[propname] set the customproperties of btn xyz to tArray Randy, it's worth looking into customPropertySets - the customproperties of an object is just the current customPopertySet of that object. Best, Mark On 25 Jun 2009, at 19:47, Klaus on-rev wrote: Hi Randy, Hi All, I've been playing with custom properties over the past several weeks for pretty much the first time. I've been able to create, fill, and empty them via script... however, I've not been to delete one via script. How is that accomplished? this is the most cumbersome thingie in the whole Rev universe :-D Fact is, you have to: ... put the customkeys of btn xyz into cp_list put lineoffset(propname_to_delete,cp_list) into line_nr delete line line_nr of cp_list set the customkeys of btn xyz to cp_list ... BTW, has this ever bee bugzilla'd as an enhancement? take care, randy hengst Best Klaus -- Klaus Major http://www.major-k.de kl...@major.on-rev.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 ___ 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: Deleting Custom Properties
Mark, Thanks for this additional tip. take care, randy - On Jun 25, 2009, at 3:23 PM, Mark Smith wrote: Klaus, a slightly simpler way is to use the fact the the customproperties of an object is an array, so: put the customproperties of btn xyz into tArray delete variable tArray[propname] set the customproperties of btn xyz to tArray Randy, it's worth looking into customPropertySets - the customproperties of an object is just the current customPopertySet of that object. Best, Mark On 25 Jun 2009, at 19:47, Klaus on-rev wrote: Hi Randy, Hi All, I've been playing with custom properties over the past several weeks for pretty much the first time. I've been able to create, fill, and empty them via script... however, I've not been to delete one via script. How is that accomplished? this is the most cumbersome thingie in the whole Rev universe :-D Fact is, you have to: ... put the customkeys of btn xyz into cp_list put lineoffset(propname_to_delete,cp_list) into line_nr delete line line_nr of cp_list set the customkeys of btn xyz to cp_list ... BTW, has this ever bee bugzilla'd as an enhancement? take care, randy hengst Best Klaus -- Klaus Major http://www.major-k.de kl...@major.on-rev.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 ___ 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: Deleting Custom Properties
I dunno, seems a bit complicated. I just dug out a stack I made a while back that I popped together to try and understand customProps (which, oddly enough, turned out to be extremely simple to understand). Now on that stack, on its single card there is a button called CusProp which contains 2 customProperties which are set up through another button with the following script: on mouseUp set the porkNbeans of btn CusProp to 547 set the custardTart of btn CusProp to Silly Sausage set the daftChap of btn CusProp to 96 end mouseUp on opening the prefs palette the customProperties of the btn CusProp can be seen to have come into existence, and their values filled in. So, tried to delete them via another button with this script: on mouseUp set the customPropertySets of btn CusProp to tArray end mouseUp which, oddly, only knocked out 'custardTart' . . . so tried this: on mouseUp set the customPropertySets of btn CusProp to tArray set the customPropertySet of btn CusProp to qArray end mouseUp ALL GONE! What I don't quite understand is why 'set the customPropertySets of btn CusProp to tArray' only removes the first customProperty, and 'set the customPropertySet of btn CusProp to qArray' by itself removes nothing at all. Mark Smith wrote: Klaus, a slightly simpler way is to use the fact the the customproperties of an object is an array, so: put the customproperties of btn xyz into tArray delete variable tArray[propname] set the customproperties of btn xyz to tArray Randy, it's worth looking into customPropertySets - the customproperties of an object is just the current customPopertySet of that object. Best, Mark On 25 Jun 2009, at 19:47, Klaus on-rev wrote: Hi Randy, Hi All, I've been playing with custom properties over the past several weeks for pretty much the first time. I've been able to create, fill, and empty them via script... however, I've not been to delete one via script. How is that accomplished? this is the most cumbersome thingie in the whole Rev universe :-D Fact is, you have to: ... put the customkeys of btn xyz into cp_list put lineoffset(propname_to_delete,cp_list) into line_nr delete line line_nr of cp_list set the customkeys of btn xyz to cp_list ... BTW, has this ever bee bugzilla'd as an enhancement? take care, randy hengst Best Klaus -- Klaus Major http://www.major-k.de kl...@major.on-rev.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: Deleting Custom Properties
I knew I was barking up the wrong tree: this: on mouseUp set the customKeys of btn CusProp to empty end mouseUp scrubbed out EVERYTHING all at once! Hey, guess what; it's there in the Documentation (although, admittedly, not expressed perticularly clearly). ___ 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: Inheritance and Custom Properties
On 4/21/09 3:38 AM, David Bovill david.bov...@gmail.com wrote: Actually you don't need to use do' dick. One of the great things about custom properties is that you can do this: put test_Prop into myCustomPropvar put the myCustomPropvar of btn 1 You can also do this with params: so in Dicks case put pCustomPropertySetName [ quote pCustomPropertyName quote ] into myCustomPropvar put the myCustomPropvar of tRevObject into tValue The first suggestion works, but not the second. The second works too after removing both occurrences of quote. Thanks for the suggestions, David. The new, improved function follows. -- Dick postScript function effectiveValue pCustomPropertyName,pCustomPropertySetName,pRevObject if pCustomPropertySetName is empty then put pCustomPropertyName into tProperty else put pCustomPropertySetName [ pCustomPropertyName ] into tProperty end if if pRevObject is empty then put long id of the target into tRevObject else put long id of pRevObject into tRevObject end if lock messages repeat until tRevObject is empty put the tProperty of tRevObject into tValue if tValue is empty then if word 1 of tRevObject is stack then delete word 1 to 3 of tRevObject else delete word 1 to 4 of tRevObject end if else exit repeat end if end repeat unlock messages return tValue end effectiveValue /postScript ___ 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: Inheritance and Custom Properties
In general it's good not to use do for repeated actions because of its speed. I've actually not done a speed test, but I'm pretty sure calling a custom prop directly (see below) is much faster. Also using message inheritance will be much faster than repeating manually through all the controls in the hierarchy. This won't matter for one-offs - but I use these techniques for geometry management and they need to be as fast as possible (without sacrificing ease of scripting or maintenance). 2009/4/20 François Chaplais francois.chapl...@mines-paristech.fr Le 15 avr. 09 à 19:05, Dick Kriesel a écrit : postScript function effectiveValue pCustomPropertyName,pCustomPropertySetName put long id of the target into tRevObject if pCustomPropertySetName is empty then put put the pCustomPropertyName of tRevObject into tValue into tStatement else put put the pCustomPropertySetName [ quote pCustomPropertyName quote ] of tRevObject into tValue into tStatement end if lock messages repeat until tRevObject is empty do tStatement if tValue is empty then if word 1 of tRevObject is stack then delete word 1 to 3 of tRevObject else delete word 1 to 4 of tRevObject end if else exit repeat end if end repeat unlock messages return tValue end effectiveValue /postScript but you do use the do command... Actually you don't need to use do' dick. One of the great things about custom properties is that you can do this: put test_Prop into myCustomPropvar put the myCustomPropvar of btn 1 You can also do this with params: so in Dicks case put pCustomPropertySetName [ quote pCustomPropertyName quote ] into myCustomPropvar put the myCustomPropvar of tRevObject into tValue There used to be a bug in which you had to be careful about spaces with the param passed - not sure if it is still there - email me if you get problems and I'll dig it out. ___ 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: Inheritance and Custom Properties
Le 21 avr. 09 à 12:38, David Bovill a écrit : In general it's good not to use do for repeated actions because of its speed. I've actually not done a speed test, but I'm pretty sure calling a custom prop directly (see below) is much faster. Also using message inheritance will be much faster than repeating manually through all the controls in the hierarchy. This won't matter for one- offs - but I use these techniques for geometry management and they need to be as fast as possible (without sacrificing ease of scripting or maintenance). . Actually you don't need to use do' dick. One of the great things about custom properties is that you can do this: put test_Prop into myCustomPropvar put the myCustomPropvar of btn 1 You can also do this with params: so in Dicks case put pCustomPropertySetName [ quote pCustomPropertyName quote ] into myCustomPropvar put the myCustomPropvar of tRevObject into tValue good to know... Thanks, David There used to be a bug in which you had to be careful about spaces with the param passed - not sure if it is still there - email me if you get problems and I'll dig it out. ___ 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: Inheritance and Custom Properties
Le 15 avr. 09 à 19:05, Dick Kriesel a écrit : On 4/15/09 4:58 AM, David Bovill david.bov...@gmail.com wrote: If you want them inherited you need to define a getprop handler. You can inherit any custom property even without getprop handlers, by walking through the object's long id until you find a value. Here's a function that does that for any given custom property name, and optionally any given custom property set name as well. If you're interested in a similar function that identifies the object that provided the effective value, let me know. As usual, watch out for line wraps imposed by email. -- Dick postScript function effectiveValue pCustomPropertyName,pCustomPropertySetName put long id of the target into tRevObject if pCustomPropertySetName is empty then put put the pCustomPropertyName of tRevObject into tValue into tStatement else put put the pCustomPropertySetName [ quote pCustomPropertyName quote ] of tRevObject into tValue into tStatement end if lock messages repeat until tRevObject is empty do tStatement if tValue is empty then if word 1 of tRevObject is stack then delete word 1 to 3 of tRevObject else delete word 1 to 4 of tRevObject end if else exit repeat end if end repeat unlock messages return tValue end effectiveValue /postScript but you do use the do command... I implemented years ago some OOP behaviour for Rinaldi's textoid HC external, with the goal of having an as flexible as possible text window management. But I had to use the do command, because I basically had to implement an custom interpreter over hypertalk. best regards, François ___ 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: Inheritance and Custom Properties
2009/4/17 Jim Bufalini j...@visitrieve.com Can you be more specific about this one command that kicks off the whole shebang? Are you using the newButton, newStack, etc. messages that then do an arbitrary getProp which triggers a sequence of copying the custom properties? Or is it simpler than that? Thanks! I tried i the last post - i an email rush at the moment - think its probably best to post actua scripts... ___ 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: Inheritance and Custom Properties
Agreed it is not real OOP inheritance. But just in case you don't get the way you use getprop/setprop handlers to achieve the same sort of automatic creation of properties that you refer to I'll give you few examples: 1. You want to create a form view, in which you place records, and you want these records to automatically inherit certain properties relating to forms - as a simple example you want each control to automatically have a property record_Value. Solution add getprop/setprops to the stack script which check for the type of controla nad return and appropriate value - all controls in the stack inherit this property without you having to do anything. 2. You want to create a series of image controls that all inherit some basic class of properties relevant to images that are not built in to the engine. Old technique create a library that implements these properties for any images that has some custom property - say uImageClass set to true or some specific class name. New technique implement a behavior and add the library scripts to the behavior - except you don't need to check for a custom property - instead you can define a single geptprop/setprop in a library - say setprop image_Class someBoolean which sets the behavior of the target image. In all these cases the inherited behavior is automatic in the sense you describe - you just issue one command to add the inherited behavior to a control. 2009/4/15 Jim Bufalini j...@visitrieve.com Dear Dick and David, I don't want to be a stickler here and keep this going on forever, ;-) but I believe the correct answer to Are *custom* properties inherited? Has to be no. While it is 100% true that handlers like setProp can be used by the application programmer to review, copy, alter and even deny a change of one custom property to others, this is not inheritance. And, of course, you can write custom handlers like Dick's. But again, this is not true inheritance. To me, the definition of inheritance is that, on the creation of an object, it automatically assumes characteristics of another object. Or on change of a property of one object, its dependent objects' properties automatically change. The key here is automatic, and not that I can program it. ;-) So for example, if you check the *Purge stack on close of a main stack, then any existing substacks, or any newly created substacks, will automatically have this property checked. If you then uncheck this property (or set it in code), in either the main stack or any of its substacks, all related stacks automatically reflect the change and this property is unchecked. You don't have to program this. And, in fact, you cannot program against this inheritance. This simply does not automatically happen with custom properties. (Now please don't point out that if you set the custom properties of a templateStack, a newly created stack will have those custom properties. ;-) Hence, custom properties are not inherited in the traditional sense. ;-) Aloha from Hawaii, Jim Bufalini -Original Message- From: use-revolution-boun...@lists.runrev.com [mailto:use-revolution- boun...@lists.runrev.com] On Behalf Of Dick Kriesel Sent: Wednesday, April 15, 2009 7:06 AM To: use-rev Subject: Re: Inheritance and Custom Properties On 4/15/09 4:58 AM, David Bovill david.bov...@gmail.com wrote: If you want them inherited you need to define a getprop handler. You can inherit any custom property even without getprop handlers, by walking through the object's long id until you find a value. Here's a function that does that for any given custom property name, and optionally any given custom property set name as well. If you're interested in a similar function that identifies the object that provided the effective value, let me know. As usual, watch out for line wraps imposed by email. -- Dick postScript function effectiveValue pCustomPropertyName,pCustomPropertySetName put long id of the target into tRevObject if pCustomPropertySetName is empty then put put the pCustomPropertyName of tRevObject into tValue into tStatement else put put the pCustomPropertySetName [ quote pCustomPropertyName quote ] of tRevObject into tValue into tStatement end if lock messages repeat until tRevObject is empty do tStatement if tValue is empty then if word 1 of tRevObject is stack then delete word 1 to 3 of tRevObject else delete word 1 to 4 of tRevObject end if else exit repeat end if end repeat unlock messages return tValue end effectiveValue /postScript ___ use-revolution mailing list use-revolution@lists.runrev.com Please visit this url to subscribe, unsubscribe and manage your subscription preferences: http
Re: Inheritance and Custom Properties
David- Wednesday, April 15, 2009, 4:58:58 AM, you wrote: If you want them inherited you need to define a getprop handler. Unfortunately, it seems that behavior controls are the exception to this. Placing the getprop handler in a behavior button does not implement inherited custom properties, while placing them in the stack script does. ...and note that you probably don't want to inherit the setprop handler: changing the value of the custom property in a child object would change the value for all objects that inherit that property. -- -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: Inheritance and Custom Properties
2009/4/16 Mark Wieder mwie...@ahsoftware.net David- Wednesday, April 15, 2009, 4:58:58 AM, you wrote: If you want them inherited you need to define a getprop handler. Unfortunately, it seems that behavior controls are the exception to this. Placing the getprop handler in a behavior button does not implement inherited custom properties, while placing them in the stack script does. Really ??? I haven't come across that! Are you sure? So far everything behaves :) as expected. Behaviors are inserted in the message path and everything below this will inherit the behavior. this is not the same for the stack - unless you attached the behavior to the stack which would be a bit odd... if you've got an example let us in... ...and note that you probably don't want to inherit the setprop handler: changing the value of the custom property in a child object would change the value for all objects that inherit that property. That all depends on how you write the getprop / setprop - the important thing is to keep them symetrical. If you want a global inherited property then you can have that with the examples I gave earlier. If you want a property that apples to each object, but can have individual instance values then you can get and set a custom property of the target to achieve that - putting something like this in the stack script would achieve that (you'd want to do something more interesting in a real world example): getprop instance_Property return the uOPN [instance_Property] of the target end instance_Property Of course you can get-and-set the data from anywhere - a text file or database... its up to you if you associate it with the target, the card, the stack, or globally etc ___ 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: Inheritance and Custom Properties
David- Thursday, April 16, 2009, 8:48:32 AM, you wrote: Really ??? I haven't come across that! Are you sure? So far everything behaves :) as expected. Behaviors are inserted in the message path and everything below this will inherit the behavior. this is not the same for the stack - unless you attached the behavior to the stack which would be a bit odd... if you've got an example let us in... My bad - it does work as advertised. I fell into a rev bug setting up my test: apparently you can't specify a button *name* as a behavior object in the property editor - given button 1 named Parent: button 1 works button Parent doesn't I forgot to go back and validate that the behavior property was set after I set it. I'm off to bugzilla now to file a report... -- -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: Inheritance and Custom Properties
Hi David, Agreed it is not real OOP inheritance. But just in case you don't get the way you use getprop/setprop handlers to achieve the same sort of automatic creation of properties that you refer to I'll give you few examples: Actually, the lights went on as soon as you first said it. :-) We've used get/setProp for quite a while, but at a more local level. For example, if you have downloaded the free ListMagic trial and create a list widget on a card, you will find a fairly large setProp in the field script of the widget with a switch statement that governs what happens when a custom property for that field changes. The matching getProp is in the ListMagic lib. But, honestly, I never thought of using this method to fake inheritance until you said it. ;-) 1. You want to create a form view, in which you place records, and you want these records to automatically inherit certain properties relating to forms - as a simple example you want each control to automatically have a property record_Value. Solution add getprop/setprops to the stack script which check for the type of controla nad return and appropriate value - all controls in the stack inherit this property without you having to do anything. 2. You want to create a series of image controls that all inherit some basic class of properties relevant to images that are not built in to the engine. Old technique create a library that implements these properties for any images that has some custom property - say uImageClass set to true or some specific class name. New technique implement a behavior and add the library scripts to the behavior - except you don't need to check for a custom property - instead you can define a single geptprop/setprop in a library - say setprop image_Class someBoolean which sets the behavior of the target image. In all these cases the inherited behavior is automatic in the sense you describe - you just issue one command to add the inherited behavior to a control. Can you be more specific about this one command that kicks off the whole shebang? Are you using the newButton, newStack, etc. messages that then do an arbitrary getProp which triggers a sequence of copying the custom properties? Or is it simpler than that? Thanks! Aloha from Hawaii, Jim Bufalini ___ 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
Inheritance and Custom Properties
Yup, it's Richmond, 2-3 years behind the times :) Well, to be honest, I've never really had the need of custom properties before. Reading the EXCELLENT RevolutionUsersGuide.pdf (and, by EXCELLENT, I mean far better in many respects than the online Documentation) I find that whether a property is inherited or not depends on mysterious decisions taken 'on high', err, well, Edinburgh; or, decisions taken along time ago by the oft-reviled Scott Rossi in MetaCard days. I know that heritable properties can be over-ridden; What is unclear to me is if properties that are not normally inherited can be set to be inherited. Now, I have started to learn about custom properties, not through any real need for them, as all I need for the goofy content delivery programs for my school I already know, but for intellectual stimulus (a bit short of that teaching kids EFL). So, I set up a stack with a card called 'WUN' and a button called 'CusProp'; and typed this into the Message box: set the porkNbeans of btn CusProp to 547 all very straightforward; and when I open the properties editor I can see the custom property 'porkNbeans' quite clearly. Decided to be clever and typed this into the Message box: set the custardTart of card WUN to 99 same as the button: worked like a charm. The made a field. and put this in the button 'CusProp': on mouseUp put the porkNbeans of btn quote CusProp quote is the porkNbeans of me into line 1 of fld Props put the custardTart of btn quote CusProp quote is the custardTart of me into line 2 of fld Props put into line 3 of fld Props put the custardTart of card quote WUN quote is the custardTart of card WUN into line 4 of fld Props end mouseUp and found that 'custardTart' of btn 'CusProp' is empty (meaning it does not have a custom property 'custardTart') so learnt that custom properties are not inherited (or, at least not 'custardTart'). Is it possible to set up custom properties so that they can be inherited? sincerely, Richmond Mathewson. A Thorn in the flesh is better than a failed Systems Development Life Cycle. ___ 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: Inheritance and Custom Properties
Hi Richmond, Yup, it's Richmond, 2-3 years behind the times :) Well, to be honest, I've never really had the need of custom properties before. Reading the EXCELLENT RevolutionUsersGuide.pdf (and, by EXCELLENT, I mean far better in many respects than the online Documentation) I find that whether a property is inherited or not depends on mysterious decisions taken 'on high', err, well, Edinburgh; or, decisions taken along time ago by the oft-reviled Scott Rossi in MetaCard days. I know that heritable properties can be over-ridden; What is unclear to me is if properties that are not normally inherited can be set to be inherited. Now, I have started to learn about custom properties, not through any real need for them, as all I need for the goofy content delivery programs for my school I already know, but for intellectual stimulus (a bit short of that teaching kids EFL). So, I set up a stack with a card called 'WUN' and a button called 'CusProp'; and typed this into the Message box: set the porkNbeans of btn CusProp to 547 all very straightforward; and when I open the properties editor I can see the custom property 'porkNbeans' quite clearly. Decided to be clever and typed this into the Message box: set the custardTart of card WUN to 99 same as the button: worked like a charm. The made a field. and put this in the button 'CusProp': on mouseUp put the porkNbeans of btn quote CusProp quote is the porkNbeans of me into line 1 of fld Props put the custardTart of btn quote CusProp quote is the custardTart of me into line 2 of fld Props put into line 3 of fld Props put the custardTart of card quote WUN quote is the custardTart of card WUN into line 4 of fld Props end mouseUp and found that 'custardTart' of btn 'CusProp' is empty (meaning it does not have a custom property 'custardTart') so learnt that custom properties are not inherited (or, at least not 'custardTart'). This is correct. Think of custom properties as arrays where the custom property set is the array variable. The custom property is the key. And the key has a value. So using your example (except I changed the name of the button to btnCustProp, so as not to be confusing) and I added custom property sets. And you use array syntax. So put this in you button: ON mouseUp pMouseBtnNo set the myCustPropSet[porkNbeans] of me to 547 set the myCustPropSet[custartTart] of me to 99 set the myCustPropSet[custartTart] of cd WUN to 100 - put (the myCustPropSet[porkNbeans] of btn btnCustProp = the myCustPropSet[porkNbeans] of me) into line 1 of fld Props put (the myCustPropSet[custartTart] of btn btnCustProp = the myCustPropSet[custartTart] of me) into line 2 of fld Props put (the myCustPropSet[custartTart] of cd WUN = the myCustPropSet[custartTart] of the owner of me) into line 4 of fld Props END mouseUp This will set lines 1, 2 and 4 to true in your field. As to inheritance, no (as far as I know) and I don't think you would want it. ;-) To reference a custom property, you must use a fully qualified path. So the above creates two separate custom property sets by the same name of myCustPropSet. One in the card and the other in the button. The card one has one custom property (key) and the button has two custom properties (keys). Because they are not inherited, you are able to set them all independently to different values, even though they all have the same names and keys. Aloha from Hawaii, Jim Bufalini ___ 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: Inheritance and Custom Properties
2009/4/15 Jim Bufalini j...@visitrieve.com Because they are not inherited, you are able to set them all independently to different values, even though they all have the same names and keys. If you want them inherited you need to define a getprop handler. getprop porkNbeans -- return your data here end porkNbeans setprop porkNbeans someValue -- set your data here end porkNbeans Put those anywhere in the hierarchy to inherit the property for all objects below it in the message path. You can check for the type of object if you want to restrict the property to particular 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: Inheritance and Custom Properties
Hi David, While very useful message handlers, I don't believe that this qualifies as object inheritance. And I don't know that someone just starting to get their arms around custom properties should attempt to mess with them. ;-) For example, your setProp example doesn't have a pass statement, so the actual custom property won't get changed. Someone just starting out with custom properties wouldn't pick up on this and just think things don't work. And there are issues of recursion if used improperly and it takes some understanding of sequencing. But, if Richmond decides to play with setProp and getProp and gets confused, you can answer his questions. ;-) Aloha from Hawaii Jim Bufalini -Original Message- From: use-revolution-boun...@lists.runrev.com [mailto:use-revolution- boun...@lists.runrev.com] On Behalf Of David Bovill Sent: Wednesday, April 15, 2009 1:59 AM To: How to use Revolution Subject: Re: Inheritance and Custom Properties 2009/4/15 Jim Bufalini j...@visitrieve.com Because they are not inherited, you are able to set them all independently to different values, even though they all have the same names and keys. If you want them inherited you need to define a getprop handler. getprop porkNbeans -- return your data here end porkNbeans setprop porkNbeans someValue -- set your data here end porkNbeans Put those anywhere in the hierarchy to inherit the property for all objects below it in the message path. You can check for the type of object if you want to restrict the property to particular 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 ___ 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: Inheritance and Custom Properties
David- Wednesday, April 15, 2009, 4:58:58 AM, you wrote: If you want them inherited you need to define a getprop handler. Thanks. In all the time I've played with getprop/setprop handlers it never occurred to me that this would implement inheritance. -- -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: Inheritance and Custom Properties
You'd have to set and retrieve the data yourself - I just put in commented out pseudo code. So: getprop porkNbeans return the uData [porkNbeans] of me to someValue end porkNbeans setprop porkNbeans someValue set the uData [porkNbeans] of me end porkNbeans That give you effective inheritance of the porkNbeans custom property. I do this for pretty well every custom property now, because it makes it so much easier to see what is going on by reading the script, and it tidies all your messy custom properties into one easy to delete set. It also give you room to grow as you may find you want to do other things while setting the property - like turn the microwave on :) 2009/4/15 Jim Bufalini j...@visitrieve.com Hi David, While very useful message handlers, I don't believe that this qualifies as object inheritance. And I don't know that someone just starting to get their arms around custom properties should attempt to mess with them. ;-) For example, your setProp example doesn't have a pass statement, so the actual custom property won't get changed. Someone just starting out with custom properties wouldn't pick up on this and just think things don't work. And there are issues of recursion if used improperly and it takes some understanding of sequencing. But, if Richmond decides to play with setProp and getProp and gets confused, you can answer his questions. ;-) Aloha from Hawaii Jim Bufalini -Original Message- From: use-revolution-boun...@lists.runrev.com [mailto:use-revolution- boun...@lists.runrev.com] On Behalf Of David Bovill Sent: Wednesday, April 15, 2009 1:59 AM To: How to use Revolution Subject: Re: Inheritance and Custom Properties 2009/4/15 Jim Bufalini j...@visitrieve.com Because they are not inherited, you are able to set them all independently to different values, even though they all have the same names and keys. If you want them inherited you need to define a getprop handler. getprop porkNbeans -- return your data here end porkNbeans setprop porkNbeans someValue -- set your data here end porkNbeans Put those anywhere in the hierarchy to inherit the property for all objects below it in the message path. You can check for the type of object if you want to restrict the property to particular 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 ___ 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: Inheritance and Custom Properties
Richmond- Wednesday, April 15, 2009, 2:22:47 AM, you wrote: Is it possible to set up custom properties so that they can be inherited? In addition to David Bovill's suggestion about using getprop and setprop handlers at a deeper level, I filed bz #3295 a bit over three years ago suggesting the addition to the language of the effective whatever. -- -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: Inheritance and Custom Properties
Yes - Mark I filed a similar enhancement request - but prefer the use of lock messages to achieve the same effect. It was turned down - mainly I think because until they started to look at behaviors and actually create some nested groups they didn't see the relevance. 2009/4/15 Mark Wieder mwie...@ahsoftware.net I filed bz #3295 a bit over three years ago suggesting the addition to the language of the effective whatever. So I think your bz #3295 is effectively the same as #3295 RunRev ended up having to implement the very same thing themselves to get behaviors working well with nested geometry - unfortunately we cannot yet create similar behaviors ourselves in any robust way without opening up our script to the infernal death grip of recursion :( ___ 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: Inheritance and Custom Properties
On 4/15/09 4:58 AM, David Bovill david.bov...@gmail.com wrote: If you want them inherited you need to define a getprop handler. You can inherit any custom property even without getprop handlers, by walking through the object's long id until you find a value. Here's a function that does that for any given custom property name, and optionally any given custom property set name as well. If you're interested in a similar function that identifies the object that provided the effective value, let me know. As usual, watch out for line wraps imposed by email. -- Dick postScript function effectiveValue pCustomPropertyName,pCustomPropertySetName put long id of the target into tRevObject if pCustomPropertySetName is empty then put put the pCustomPropertyName of tRevObject into tValue into tStatement else put put the pCustomPropertySetName [ quote pCustomPropertyName quote ] of tRevObject into tValue into tStatement end if lock messages repeat until tRevObject is empty do tStatement if tValue is empty then if word 1 of tRevObject is stack then delete word 1 to 3 of tRevObject else delete word 1 to 4 of tRevObject end if else exit repeat end if end repeat unlock messages return tValue end effectiveValue /postScript ___ 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: Inheritance and Custom Properties
Richmond Mathewson wrote: I find that whether a property is inherited or not depends on mysterious decisions taken 'on high', err, well, Edinburgh; or, decisions taken along time ago by the oft-reviled Scott Rossi in MetaCard days. Just for the record, Scott Rossi is beloved and adored by all. Scott Raney, on the other hand, got mixed reviews. ;) -- Jacqueline Landman Gay | jac...@hyperactivesw.com 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
Inheritance and Custom Properties
J. Landman Gay wrote: Just for the record, Scott Rossi is beloved and adored by all. Scott Raney, on the other hand, got mixed reviews. ;) I'm sorry! speaking as a Scot with one 't', I find Scotts with two 't's (who aren't even Scots) a bit confusing; and when there are 'r's involved I always make an ar*e of things :) sincerely, Richmond Mathewson. A Thorn in the flesh is better than a failed Systems Development Life Cycle. ___ 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: Inheritance and Custom Properties
Dear Dick and David, I don't want to be a stickler here and keep this going on forever, ;-) but I believe the correct answer to Are *custom* properties inherited? Has to be no. While it is 100% true that handlers like setProp can be used by the application programmer to review, copy, alter and even deny a change of one custom property to others, this is not inheritance. And, of course, you can write custom handlers like Dick's. But again, this is not true inheritance. To me, the definition of inheritance is that, on the creation of an object, it automatically assumes characteristics of another object. Or on change of a property of one object, its dependent objects' properties automatically change. The key here is automatic, and not that I can program it. ;-) So for example, if you check the *Purge stack on close of a main stack, then any existing substacks, or any newly created substacks, will automatically have this property checked. If you then uncheck this property (or set it in code), in either the main stack or any of its substacks, all related stacks automatically reflect the change and this property is unchecked. You don't have to program this. And, in fact, you cannot program against this inheritance. This simply does not automatically happen with custom properties. (Now please don't point out that if you set the custom properties of a templateStack, a newly created stack will have those custom properties. ;-) Hence, custom properties are not inherited in the traditional sense. ;-) Aloha from Hawaii, Jim Bufalini -Original Message- From: use-revolution-boun...@lists.runrev.com [mailto:use-revolution- boun...@lists.runrev.com] On Behalf Of Dick Kriesel Sent: Wednesday, April 15, 2009 7:06 AM To: use-rev Subject: Re: Inheritance and Custom Properties On 4/15/09 4:58 AM, David Bovill david.bov...@gmail.com wrote: If you want them inherited you need to define a getprop handler. You can inherit any custom property even without getprop handlers, by walking through the object's long id until you find a value. Here's a function that does that for any given custom property name, and optionally any given custom property set name as well. If you're interested in a similar function that identifies the object that provided the effective value, let me know. As usual, watch out for line wraps imposed by email. -- Dick postScript function effectiveValue pCustomPropertyName,pCustomPropertySetName put long id of the target into tRevObject if pCustomPropertySetName is empty then put put the pCustomPropertyName of tRevObject into tValue into tStatement else put put the pCustomPropertySetName [ quote pCustomPropertyName quote ] of tRevObject into tValue into tStatement end if lock messages repeat until tRevObject is empty do tStatement if tValue is empty then if word 1 of tRevObject is stack then delete word 1 to 3 of tRevObject else delete word 1 to 4 of tRevObject end if else exit repeat end if end repeat unlock messages return tValue end effectiveValue /postScript ___ 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: Inheritance and Custom Properties
On 4/15/09 2:28 PM, Jim Bufalini j...@visitrieve.com wrote: Hence, custom properties are not inherited in the traditional sense. ;-) Agreed. Even with the technique I offered, the effective inheritance is based only on Rev's owner hierarchy, rather than on anyone's class hierarchy. But Rev 4.0 may offer something much better ... -- Dick ___ 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
global variables vs. custom properties
Hello, I know, that similar topics has been discussed a few time, but didn't found any hard facts It is the usage of global variables vs. custom properties for non persistant values, used at different parts within the app. I know, that most people prefer custom properties, but is it just a question of school, or is there perhaps a difference in memory usage or other hard facts? Thanks Tiemo ___ 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: global variables vs. custom properties
Hi Tiemo,: I know, that most people prefer custom properties, but is it just a question of school, or is there perhaps a difference in memory usage or other hard facts? Custom properties are stored within the stack file when it is saved, whereas globals die when the Rev engine or your standalone quits. So if your variables are non-persistant, then globals better fulfill that function. If you have variables that are populated after startup and don't need to persist after shut down, putting them in custom properties simply increases the physical size of the stack file for no useful purpose. 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: global variables vs. custom properties
Another difference is that globals work across all open stacks - they really are global. If you have a program that has multiple stacks (i.e. documents) and set the variable it will be the same across all the stacks. I got tripped up by this when I expected a global to be used anywhere within that stack but each stack would have its own value for the variable. In my case storing it in the custom properties of the stack not only kept the value global for that stack it also allowed me to save the information. Bill Vlahos On Jan 16, 2009, at 7:00 AM, Rob Cozens wrote: Hi Tiemo,: I know, that most people prefer custom properties, but is it just a question of school, or is there perhaps a difference in memory usage or other hard facts? Custom properties are stored within the stack file when it is saved, whereas globals die when the Rev engine or your standalone quits. So if your variables are non-persistant, then globals better fulfill that function. If you have variables that are populated after startup and don't need to persist after shut down, putting them in custom properties simply increases the physical size of the stack file for no useful purpose. 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: global variables vs. custom properties
There are also a drawbacks to gobals when designing reuseable functions If there is a global you like to use, say gRawTextString and gFormattedTextString, you could have situations where two different stacks you are developing are using the same names. This means that script debugging can be made more difficult if both stacks are open. One situation where this occurs is when you make your own Ask, Answer dialog boxes and put them in to different stacks. Another is when you make plugin stacks of your library routines. A specific example for me is the management of sockets in some of my networking apps. Things like StartUDP, StopUDP, gHostIP, gServerList, gFTPaddressWithLoginPswd, StartTcpIpSession, gIsRunning, gPacketToSend will obviously not work properly if I have two or more communication stacks open. Custom properties are good in those situations because then either have specific, unambiguous locations or are assumed to be local (eg. on opencard set the cpsTimeData[cpFirstOpened] of this card to the seconds Since globals are in memory space that is owned by Revolution and not the stack or library/plugin script that uses them, they don't die until you quit Revolution (large variable sizes remain in memory). A custom property is put into memory when the stack is opened, then purged when closed. A little more info for that might help. Jim Ault Las Vegas On 1/16/09 7:00 AM, Rob Cozens rcoz...@pon.net wrote: Hi Tiemo,: I know, that most people prefer custom properties, but is it just a question of school, or is there perhaps a difference in memory usage or other hard facts? Custom properties are stored within the stack file when it is saved, whereas globals die when the Rev engine or your standalone quits. So if your variables are non-persistant, then globals better fulfill that function. If you have variables that are populated after startup and don't need to persist after shut down, putting them in custom properties simply increases the physical size of the stack file for no useful purpose. 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
AW: global variables vs. custom properties
Hi Rob, Bill and Jim, It seems that the main difference in usage is, if you want / must differentiate between different stacks and the purge of memory, when using different stacks - as you have outlined. Thank you for clarifying Tiemo -Ursprüngliche Nachricht- Von: use-revolution-boun...@lists.runrev.com [mailto:use-revolution- boun...@lists.runrev.com] Im Auftrag von Jim Ault Gesendet: Freitag, 16. Januar 2009 16:41 An: How to use Revolution Betreff: Re: global variables vs. custom properties There are also a drawbacks to gobals when designing reuseable functions If there is a global you like to use, say gRawTextString and gFormattedTextString, you could have situations where two different stacks you are developing are using the same names. This means that script debugging can be made more difficult if both stacks are open. One situation where this occurs is when you make your own Ask, Answer dialog boxes and put them in to different stacks. Another is when you make plugin stacks of your library routines. A specific example for me is the management of sockets in some of my networking apps. Things like StartUDP, StopUDP, gHostIP, gServerList, gFTPaddressWithLoginPswd, StartTcpIpSession, gIsRunning, gPacketToSend will obviously not work properly if I have two or more communication stacks open. Custom properties are good in those situations because then either have specific, unambiguous locations or are assumed to be local (eg. on opencard set the cpsTimeData[cpFirstOpened] of this card to the seconds Since globals are in memory space that is owned by Revolution and not the stack or library/plugin script that uses them, they don't die until you quit Revolution (large variable sizes remain in memory). A custom property is put into memory when the stack is opened, then purged when closed. A little more info for that might help. Jim Ault Las Vegas On 1/16/09 7:00 AM, Rob Cozens rcoz...@pon.net wrote: Hi Tiemo,: I know, that most people prefer custom properties, but is it just a question of school, or is there perhaps a difference in memory usage or other hard facts? Custom properties are stored within the stack file when it is saved, whereas globals die when the Rev engine or your standalone quits. So if your variables are non-persistant, then globals better fulfill that function. If you have variables that are populated after startup and don't need to persist after shut down, putting them in custom properties simply increases the physical size of the stack file for no useful purpose. 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 ___ 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: global variables vs. custom properties
Tiemo Hollmann wrote: I know, that similar topics has been discussed a few time, but didn't found any hard facts It is the usage of global variables vs. custom properties for non persistant values, used at different parts within the app. I know, that most people prefer custom properties, but is it just a question of school, or is there perhaps a difference in memory usage or other hard facts? The others here have covered the differences well, and all I could add is a note about style and efficiency. For myself, it feels most natural to use properties as instance variables for objects; since they are bound to objects, I tend to use them for object-specific data. And since they can be stored in a stack file, they're also useful for general data like preferences or documents since it's easy to save the stack file as we would any other data file. What I dislike about using properties for general data is having to remember where they are, and to include the object specifier in the access call: put the uProp of btn 1 of stack MyData into tVar With globals it seems a bit more fluid to just write: put gValue into tVar But of course globals require a declaration, which can be made once for an entire script so it's only one more line, but it's still one more line. So for some things I make accessor functions: put MyValue() into tVar ...where MyValue is a function somewhere in the message path that figures out for me where the data is and returns it. Accessors give me the option of changing how and where data is stored at any time without having to modify any scripts that use them, and I don't need to type the object specifiers as with properties or the declaration as with globals. But the convenience of accessor functions come at a small price in performance. I wrote the benchmarking script below some years ago to measure the relative performance of globals, properties, and functions for obtaining values, and have run it against most engine versions released since with fairly consistent results: BENCHMARK SCRIPTS: -- In button: global gTest on mouseUp set the cTest of me to 100 put 100 into gTest put 100 into tTimes -- -- Global: put the milliseconds into tStart repeat tTimes get gTest end repeat put Global: the (milliseconds - tStart)/tTimes into tOut -- -- Property: put the milliseconds into tStart repeat tTimes get the uTest of me end repeat put cr Property: ( the milliseconds - tStart)/tTimes after tOut -- -- Function: put the millisecs into tStart repeat tTimes get FooTest() end repeat put cr Function: ( the milliseconds - tStart)/tTimes after tOut -- put tOut end mouseUp -- in card: function FooTest return 100 end FooTest RESULTS: Global: 0.00023 Property: 0.00151 Function: 0.00198 For computationally intensive operations, the benefits of globals are clear. But note that the times shown are in milliseconds per iteration, so while there is a relative benefit to using globals over properties or functions, the benefit is so small that it makes little difference for most operations. As much as I like to keep an eye on performance when designing an application's internal API, I have to balance runtime performance with development efficiency, making decisions on a case-by-case basis as to which will deliver the most benefit overall. In a repeat loop processing lots of data I'll usually choose the fastest method, willing to add a few comments to clarify anything that may not be self-evident. But for things that happen in response to user actions (selecting a menu item, clicking a button, etc.), the user is so much slower than the computer that I can safely afford to take liberties with a few fractions of a millisecond if it makes my work in delivering the feature that much simpler to write and maintain. -- 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: global variables vs. custom properties
In addition to all that has been said, there is another issue with properties. With a variable you can execute chunk statements. Not so with properties. You could with a variable for example say: put 25 into line 3 of myVariable You could NOT say: put 25 into line 3 of the myVariable of this stack You would first have to get the property into a variable, then work with it, then set the property again. Another thing that I like to use properties for is survival through compiles. Script Local variables get wiped on compiles so if you have script local environment variables that get initialized to some value that the operation of your app depends upon, and you edit and compile the script, your app breaks and you have to reinitialize everything. A fix for that is to save your critical environment data to properties at the end of your critical processes, and then check for the state of a script local variable before executing any critical process. If the Script Local variable is not what it ought to be, then you run a resume function that reads the properties back into your variables so your app is in the state it was before compiling. A bit tedious I agree. Wouldn't it be nice if someone could write a plugin that did it for you? I would pay good money for that! cough glx2 cough Bob Sneidar IT Manager Logos Management Calvary Chapel CM On Jan 16, 2009, at 12:51 AM, Tiemo Hollmann TB wrote: Hello, I know, that similar topics has been discussed a few time, but didn't found any hard facts It is the usage of global variables vs. custom properties for non persistant values, used at different parts within the app. I know, that most people prefer custom properties, but is it just a question of school, or is there perhaps a difference in memory usage or other hard facts? Thanks Tiemo ___ 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: global variables vs. custom properties
Bob Sneidar wrote: Another thing that I like to use properties for is survival through compiles. Script Local variables get wiped on compiles so if you have script local environment variables that get initialized to some value that the operation of your app depends upon, and you edit and compile the script, your app breaks and you have to reinitialize everything. A fix for that is to save your critical environment data to properties at the end of your critical processes, and then check for the state of a script local variable before executing any critical process. If the Script Local variable is not what it ought to be, then you run a resume function that reads the properties back into your variables so your app is in the state it was before compiling. A bit tedious I agree. Wouldn't it be nice if someone could write a plugin that did it for you? I would pay good money for that! cough glx2 cough No need. Turn on variable preservation in the Script pane of your Preferences. All done. :) -- Jacqueline Landman Gay | jac...@hyperactivesw.com 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: backscript and custom properties
Mark, If not a bug, it's very close to it: if you modify the content of the CP in the inspector, for my example by adding The small mammal species at the beginning of the first line, the CP becomes The small mammal species Microtus agrestis lives in marshy meadows and the lines 2 and 3 are lost... The only secure way if you want to modify the CP in the inspector it to rewrite it entirely (and then to change some references in the getprop if necessary). Best Jacques Le 24 déc. 2008 à 04:38, Mark Smith a écrit : Jaques, apologies for replying to what I thought you wrote instead of what you actually wrote :) I've just tried something similar to what you describe, and you're right! I never knew this - I guess this is because the property inspector is simply another stack that does it's stuff in it's own script rather than some behind-behand-the-scenes engine function. I think I'd agree that it's not necessarily desirable - I wonder if it's worth calling it a bug? Best, Mark On 23 Dec 2008, at 23:18, Jacques Hausser wrote: Thank you Mark, I didn't speak about setprop (it's perfectly logic, even if not compulsory, that a setprop would modify a property) , but about a getprop, which, in this case, doesn't change the CP - I tried that: a CP consisting of a basic sentence in a first line, say is living in - right or false ?, a second line with a list of species names sparated by comma and a third line with a list of biotops separated by comma. The getprop takes randomly an item in the second line to replace and an item in the third line to replace . And when you look at the property in the inspector you read at the first line something (different each time) like Microtus agrestis is living in marshy meadows - right or false ?. That's exactly what I want when running the stack, but I would like to see is living in - right or false ? in the inspector - that is the real content of the CP (the pure CP ;o)) My example is perfectly stupid, because it would be far simpler to drop the getprop and to put it's statements into the function but well, it's only an example, and it works... the button's back script is: function DisplayQuestion return the question of me end displayquestion getprop the question put line 1 of the question of me into laquestion put item (random(30)) of line 2 of the question of me into word 1 of laquestion put item (random(21)) of line 3 of the question of me into word 5 of laquestion return laquestion end the question and anywhere in the stack: put DisplayQuestion() into fld SuchAndSuch I was just amazed to discover it was possible to use CPs and getprop in a backscript... after all, the command is not Insert button truc into back but Insert the script of button truc into back... Jacques Le 23 déc. 2008 à 20:51, Mark Smith a écrit : Jaques, you're right - the script can still refer to 'me'. I use buttons as libraries quite often, and the fact that a button's CPs are available can be very useful. I don't tend to use getProp and setProp handlers in those 'button' libraries much - you'd still have to refer to the button's name or ID, and I generally just want a libraries commands and function available. I'm not sure what you'd expect a setProp handler to do other than modify a property, so I don't think I understand what you mean by a 'pure' custom property... Best, Mark On 23 Dec 2008, at 17:45, Jacques Hausser wrote: Hello everybody I just discovered accidentally that when a button's script is inserted as a backscript, it doesn't go there alone, but takes with it its custom properties, getprop and tutti quanti. That could be very useful... Has somebody some experience with this feature ? (I discovered also that the inspector doesn't display the pure custom property, but the property as modified by the getprop... that is perhaps not so good). Happy Christmas (or any other solstice-linked celebration) to you. Jacques ** Prof. Jacques Hausser Department of Ecology and Evolution Biophore / Sorge University of Lausanne CH 1015 Lausanne please use my private address: 6 route de Burtigny CH-1269 Bassins tel/fax:++ 41 22 366 19 40 mobile: ++ 41 79 757 05 24 E-Mail: jacques.haus...@unil.ch *** ___ 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
backscript and custom properties
Hello everybody I just discovered accidentally that when a button's script is inserted as a backscript, it doesn't go there alone, but takes with it its custom properties, getprop and tutti quanti. That could be very useful... Has somebody some experience with this feature ? (I discovered also that the inspector doesn't display the pure custom property, but the property as modified by the getprop... that is perhaps not so good). Happy Christmas (or any other solstice-linked celebration) to you. Jacques ** Prof. Jacques Hausser Department of Ecology and Evolution Biophore / Sorge University of Lausanne CH 1015 Lausanne please use my private address: 6 route de Burtigny CH-1269 Bassins tel/fax:++ 41 22 366 19 40 mobile: ++ 41 79 757 05 24 E-Mail: jacques.haus...@unil.ch *** ___ 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: backscript and custom properties
Jaques, you're right - the script can still refer to 'me'. I use buttons as libraries quite often, and the fact that a button's CPs are available can be very useful. I don't tend to use getProp and setProp handlers in those 'button' libraries much - you'd still have to refer to the button's name or ID, and I generally just want a libraries commands and function available. I'm not sure what you'd expect a setProp handler to do other than modify a property, so I don't think I understand what you mean by a 'pure' custom property... Best, Mark On 23 Dec 2008, at 17:45, Jacques Hausser wrote: Hello everybody I just discovered accidentally that when a button's script is inserted as a backscript, it doesn't go there alone, but takes with it its custom properties, getprop and tutti quanti. That could be very useful... Has somebody some experience with this feature ? (I discovered also that the inspector doesn't display the pure custom property, but the property as modified by the getprop... that is perhaps not so good). Happy Christmas (or any other solstice-linked celebration) to you. Jacques ** Prof. Jacques Hausser Department of Ecology and Evolution Biophore / Sorge University of Lausanne CH 1015 Lausanne please use my private address: 6 route de Burtigny CH-1269 Bassins tel/fax:++ 41 22 366 19 40 mobile: ++ 41 79 757 05 24 E-Mail: jacques.haus...@unil.ch *** ___ 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: backscript and custom properties
Thank you Mark, I didn't speak about setprop (it's perfectly logic, even if not compulsory, that a setprop would modify a property) , but about a getprop, which, in this case, doesn't change the CP - I tried that: a CP consisting of a basic sentence in a first line, say is living in - right or false ?, a second line with a list of species names sparated by comma and a third line with a list of biotops separated by comma. The getprop takes randomly an item in the second line to replace and an item in the third line to replace . And when you look at the property in the inspector you read at the first line something (different each time) like Microtus agrestis is living in marshy meadows - right or false ?. That's exactly what I want when running the stack, but I would like to see is living in - right or false ? in the inspector - that is the real content of the CP (the pure CP ;o)) My example is perfectly stupid, because it would be far simpler to drop the getprop and to put it's statements into the function but well, it's only an example, and it works... the button's back script is: function DisplayQuestion return the question of me end displayquestion getprop the question put line 1 of the question of me into laquestion put item (random(30)) of line 2 of the question of me into word 1 of laquestion put item (random(21)) of line 3 of the question of me into word 5 of laquestion return laquestion end the question and anywhere in the stack: put DisplayQuestion() into fld SuchAndSuch I was just amazed to discover it was possible to use CPs and getprop in a backscript... after all, the command is not Insert button truc into back but Insert the script of button truc into back... Jacques Le 23 déc. 2008 à 20:51, Mark Smith a écrit : Jaques, you're right - the script can still refer to 'me'. I use buttons as libraries quite often, and the fact that a button's CPs are available can be very useful. I don't tend to use getProp and setProp handlers in those 'button' libraries much - you'd still have to refer to the button's name or ID, and I generally just want a libraries commands and function available. I'm not sure what you'd expect a setProp handler to do other than modify a property, so I don't think I understand what you mean by a 'pure' custom property... Best, Mark On 23 Dec 2008, at 17:45, Jacques Hausser wrote: Hello everybody I just discovered accidentally that when a button's script is inserted as a backscript, it doesn't go there alone, but takes with it its custom properties, getprop and tutti quanti. That could be very useful... Has somebody some experience with this feature ? (I discovered also that the inspector doesn't display the pure custom property, but the property as modified by the getprop... that is perhaps not so good). Happy Christmas (or any other solstice-linked celebration) to you. Jacques ** Prof. Jacques Hausser Department of Ecology and Evolution Biophore / Sorge University of Lausanne CH 1015 Lausanne please use my private address: 6 route de Burtigny CH-1269 Bassins tel/fax:++ 41 22 366 19 40 mobile: ++ 41 79 757 05 24 E-Mail: jacques.haus...@unil.ch *** ___ 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 ** Prof. Jacques Hausser Department of Ecology and Evolution Biophore / Sorge University of Lausanne CH 1015 Lausanne please use my private address: 6 route de Burtigny CH-1269 Bassins tel/fax:++ 41 22 366 19 40 mobile: ++ 41 79 757 05 24 E-Mail: jacques.haus...@unil.ch *** ___ 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: backscript and custom properties
Jaques, apologies for replying to what I thought you wrote instead of what you actually wrote :) I've just tried something similar to what you describe, and you're right! I never knew this - I guess this is because the property inspector is simply another stack that does it's stuff in it's own script rather than some behind-behand-the-scenes engine function. I think I'd agree that it's not necessarily desirable - I wonder if it's worth calling it a bug? Best, Mark On 23 Dec 2008, at 23:18, Jacques Hausser wrote: Thank you Mark, I didn't speak about setprop (it's perfectly logic, even if not compulsory, that a setprop would modify a property) , but about a getprop, which, in this case, doesn't change the CP - I tried that: a CP consisting of a basic sentence in a first line, say is living in - right or false ?, a second line with a list of species names sparated by comma and a third line with a list of biotops separated by comma. The getprop takes randomly an item in the second line to replace and an item in the third line to replace . And when you look at the property in the inspector you read at the first line something (different each time) like Microtus agrestis is living in marshy meadows - right or false ?. That's exactly what I want when running the stack, but I would like to see is living in - right or false ? in the inspector - that is the real content of the CP (the pure CP ;o)) My example is perfectly stupid, because it would be far simpler to drop the getprop and to put it's statements into the function but well, it's only an example, and it works... the button's back script is: function DisplayQuestion return the question of me end displayquestion getprop the question put line 1 of the question of me into laquestion put item (random(30)) of line 2 of the question of me into word 1 of laquestion put item (random(21)) of line 3 of the question of me into word 5 of laquestion return laquestion end the question and anywhere in the stack: put DisplayQuestion() into fld SuchAndSuch I was just amazed to discover it was possible to use CPs and getprop in a backscript... after all, the command is not Insert button truc into back but Insert the script of button truc into back... Jacques Le 23 déc. 2008 à 20:51, Mark Smith a écrit : Jaques, you're right - the script can still refer to 'me'. I use buttons as libraries quite often, and the fact that a button's CPs are available can be very useful. I don't tend to use getProp and setProp handlers in those 'button' libraries much - you'd still have to refer to the button's name or ID, and I generally just want a libraries commands and function available. I'm not sure what you'd expect a setProp handler to do other than modify a property, so I don't think I understand what you mean by a 'pure' custom property... Best, Mark On 23 Dec 2008, at 17:45, Jacques Hausser wrote: Hello everybody I just discovered accidentally that when a button's script is inserted as a backscript, it doesn't go there alone, but takes with it its custom properties, getprop and tutti quanti. That could be very useful... Has somebody some experience with this feature ? (I discovered also that the inspector doesn't display the pure custom property, but the property as modified by the getprop... that is perhaps not so good). Happy Christmas (or any other solstice-linked celebration) to you. Jacques ** Prof. Jacques Hausser Department of Ecology and Evolution Biophore / Sorge University of Lausanne CH 1015 Lausanne please use my private address: 6 route de Burtigny CH-1269 Bassins tel/fax:++ 41 22 366 19 40 mobile: ++ 41 79 757 05 24 E-Mail: jacques.haus...@unil.ch *** ___ 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 ** Prof. Jacques Hausser Department of Ecology and Evolution Biophore / Sorge University of Lausanne CH 1015 Lausanne please use my private address: 6 route de Burtigny CH-1269 Bassins tel/fax:++ 41 22 366 19 40 mobile: ++ 41 79 757 05 24 E-Mail: jacques.haus...@unil.ch *** ___ use-revolution mailing list use-revolution@lists.runrev.com Please visit this url to subscribe, unsubscribe and manage your subscription preferences: http
Font size in Inspector for Custom Properties
I would like to increase the size of the font in the Inspector when using custom properties. However, I have not found a way to do this. I tried the preferences for the script editor but that does not work. Does anybody know how to change the font size in the inspector when using custom properties? -- View this message in context: http://www.nabble.com/Font-size-in-Inspector-for-Custom-Properties-tp15777289p15777289.html Sent from the Revolution - User mailing list archive at Nabble.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: Font size in Inspector for Custom Properties
Bonjour Charles, Le 1 mars 08 à 16:38, Charles Szasz a écrit : I would like to increase the size of the font in the Inspector when using custom properties. However, I have not found a way to do this. I tried the preferences for the script editor but that does not work. Does anybody know how to change the font size in the inspector when using custom properties? 1. make a copy of Toolset/revpalette.rev in case of problem :-) 2. open Rev and check View/Revolution UI Elements in Lists. 3. open app browser and display in app browser the card named 'revCustomProperties' of revTemplatePalette stack. 4. open the inspector for 'property contents' field and display 'Text Formatting' pane. 5. Increase text size to 13 or 14. 6. Use contextual menu on revTemplatePalette stack icon in app browser to save this stack. You are done. Best regards from Paris, Eric Chatonet. Plugins and tutorials for Revolution: http://www.sosmartsoftware.com/ Email: [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
Re: Font size in Inspector for Custom Properties
Eric, Thanks! Your suggestion worked great! It is too bad that there is not a pref for the font size in custom properties. Charles Szasz wrote: I would like to increase the size of the font in the Inspector when using custom properties. However, I have not found a way to do this. I tried the preferences for the script editor but that does not work. Does anybody know how to change the font size in the inspector when using custom properties? -- View this message in context: http://www.nabble.com/Font-size-in-Inspector-for-Custom-Properties-tp15777289p15779111.html Sent from the Revolution - User mailing list archive at Nabble.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
Temporary custom properties
Hey, does anyone have a suggestion about what is the best kind of (non-visible) object to create on the fly for temporarily storing custom properties? In other words, I want to use custom properties like global variables, but I want to put them in something that only exists during program execution and that won't get saved with my project. Or, should I be using something besides custom properties for keeping global, transient values that the program only needs during execution? Never miss a thing. Make Yahoo your home page. http://www.yahoo.com/r/hs ___ 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: Temporary custom properties
why would you not use a global variable? A big feature of custom properties is that they can persist from execution to execution. A global goes away after execution. sqb Hey, does anyone have a suggestion about what is the best kind of (non-visible) object to create on the fly for temporarily storing custom properties? In other words, I want to use custom properties like global variables, but I want to put them in something that only exists during program execution and that won't get saved with my project. Or, should I be using something besides custom properties for keeping global, transient values that the program only needs during execution? -- 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: Temporary custom properties
Well, there are several options that don't require any real effort. Any object can store custom properties. Any object can store these in property sets. - put this into a new stack, then double click on mouseDoubleUp set the closet[shoebox1] of this stack to good vibes set the closet[shoebox2] of this stack to better vibes set the musicTrack[slideOne] of this stack to Peaceful sounds.aif set the videoTrack[slideOne] of this stack to demo widget.mov put the custompropertysets of this stack into listing put return return after listing get the customproperties[closet] of this stack combine it using cr and tab put it after listing put listing into msg set the custompropertysets of this stack to empty -- *poof they are gone* end mouseDoubleUp end copy set the property set myTempData of this stack to empty poof they are gone set the property set myTempData of card 1 of this stack to empty poof they are gone set the property set myTempData of card id 3422 of this stack to empty poof they are gone Globals have the advantage that they can be used by any stack that is open, since globals are owned by Revolution. They persist until Revolution quits or you use the command 'delete global myTempData' The ease of using the custom properites is that you can set the customPropertiesSets of this stack to empty and delete all the data in one line of code. Hope this helps. There is more than one way to design your variable handling, all of which work, most of which involve keeping the data in RAM when the stack is opened. Jim Ault Las Vegas On 2/14/08 2:05 PM, Russell Martin [EMAIL PROTECTED] wrote: Hey, does anyone have a suggestion about what is the best kind of (non-visible) object to create on the fly for temporarily storing custom properties? In other words, I want to use custom properties like global variables, but I want to put them in something that only exists during program execution and that won't get saved with my project. Or, should I be using something besides custom properties for keeping global, transient values that the program only needs during execution? ___ 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
