Re: Implementing a library of behavior buttons across multiple applications
Peter Haworth wrote: Thanks Richard. So the SB pulls in ALL the stack files defined to it int the application and I don;t have to send any of them out with the app, right? I don't use that feature of Rev myself, but yes, I believe that's what it's designed to do. -- 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: Implementing a library of behavior buttons across multiple applications
Hi Peter, No, you don't need to include the operating system's path to the stack file. For example, the following is a correct reference for a behavior: button id 1015 of stack Untitled 1 You can keep one copy of your stack with parent objects on your hard disk and add this stack to the stackfiles property of the mainstack of your project. When you build the standalone, the stack will be copied into your standalone and above reference will still work. -- 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 projects. Contact me for a quote http://economy-x-talk.com/contact.html Download Clipboard Link http://clipboardlink.economy-x-talk.com and share the clipboard of your computer over the local network. On 24 mei 2010, at 22:03, Peter Haworth wrote: I'm trying to figure out the best way to make a library of behavior buttons available to multiple applications. I originally developed the library as a substack of my application but would now like to move it to a separate .rev file and refer to it from other applications. Seems like that gives me a single maintenance point - fix any behavior problems in the library and it's automatically fixed in all applications. However, it's feeling like this isn't a practical solution. As I understand it, the behavior property of an object uses the long id of the button it refers to and I think the long id includes the operating system path to the .rev file that the button is in. Just for development purposes, I have three different folders I use - one for code and test, another for QA, and anther for the final application. SO if I set the behavior to point to my library of behaviors in the code and test folder, then move the app's .rev file to the QA folder, the behavior properties will still point to the behavior library of in the code and test folder. And so on. I'm sure there much more experienced users than me out there who have run into this problem and hoping they can share how they dealt with it. Only thing I can think of is a script that runs during installtion to go find all controls with a behavior property set and change it to the correct one. Pete Haworth ___ 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: Implementing a library of behavior buttons across multiple applications
Thanks for the explanation Richard. This stuff isn't made any easier by the fact that there are multiple names available for the same thing - behavior=parentScript apparently. Getting back to Mark's answer and the use of stack files, I see two separate places where additional stack files can be specified - the stackFiles property of the main Stack (or the equivalent pane in the main stack inspector), and the Stacks pane of the Standalone Application Settings which gives rise to the question, what is the relationship between these two settings? Does one override the other? Is stackFiles operative for the development environment only and the standalone setting for standalone applications only? Pete Haworth On May 25, 2010, at 10:00 AM, use-revolution-requ...@lists.runrev.com wrote: Message: 7 Date: Tue, 25 May 2010 09:33:27 -0700 From: Richard Gaskin ambassa...@fourthworld.com Subject: Re: use-revolution Digest, Vol 80, Issue 81 To: How to use Revolution use-revolution@lists.runrev.com Cc: Runtime Revolution Support supp...@runrev.com Message-ID: 4bfbfbd7.7090...@fourthworld.com Content-Type: text/plain; charset=ISO-8859-1; format=flowed Peter Haworth wrote: I'm glad to gear such a simple solution! My concerns were all based on the following in the dictionary entry for behavior: The behavior property is a reference to a button containing the script to use. It is in the format of a long ID. I guess I need to be more careful about believing what the dictionary says! Pete Haworth The docs are kinda correct, but just don't tell the whole story (I'm cc'ing support here so the Dictionary entry can be updated to reflect the full story): You can use the long ID of a button to set the value of the behavior property for an object, but once it's set it gets stored using only the short name of the stack the behavior button is in. This is explained more fully in the ParentScriptNotes.txt document included with the Rev install: PARENT SCRIPTS - RESOLUTION A control's parent script reference is saved in the stackfile as three pieces of information: 1) button id 2) stack name 3) mainstack name (if stack is substack) This is the minimum required information to uniquely identify a button within a running Revolution environment. Immediately after loading a stack file, an attempt is made to resolve all parentScript references - the engine acts as if it constructs a control reference: button id id of stack stack name [ of stack mainstack name ] And attempts to access it. Thus, the stackFiles property will be searched as appropriate and any needed stacks will be loaded. -- 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: Implementing a library of behavior buttons across multiple applications
Peter Haworth wrote: Thanks for the explanation Richard. This stuff isn't made any easier by the fact that there are multiple names available for the same thing - behavior=parentScript apparently. You can safely ignore parentScript. That was the name that I used when I first proposed this feature many years ago, having picked it up from meetings with the SuperCard team years earlier when they were considering it. Rev adopted it for an early beta distribution, but by Beta 2 they had come up with behavior instead, and noted in the ParentScript Notes that parentScript is deprecated; while it's currently accepted as a synonym for behavior to help a few people who started building big projects with that early beta, it won't live forever. Getting back to Mark's answer and the use of stack files, I see two separate places where additional stack files can be specified - the stackFiles property of the main Stack (or the equivalent pane in the main stack inspector), and the Stacks pane of the Standalone Application Settings which gives rise to the question, what is the relationship between these two settings? Does one override the other? Is stackFiles operative for the development environment only and the standalone setting for standalone applications only? Two different things: The Stacks pane in the SB is used for copying separate stack files into the file that will become the standalone. The stackfiles property of a stack is a list which allows the engine to easily locate stacks which aren't in the stackfile so that you can still refer to them by just their short name in your scripts. For example, if you have a stack named Behaviors in a stack file named Behaviors.rev in a folder named Components which is in the same folder as your stack file or standalone, you can set the stackfile's property of your stack to: Behaviors,Components/Behaviors.rev ...and the engine will then know exactly where to find the stack whenever your scripts refer to a stack named Behaviors. -- 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: Implementing a library of behavior buttons across multiple applications
Thanks Richard. So the SB pulls in ALL the stack files defined to it int the application and I don;t have to send any of them out with the app, right? Pete Haworth http://www.mollysrevenge.com http://www.sonicbids.com/MollysRevenge http://www.myspace.com/mollysrevengeband On May 25, 2010, at 1:15 PM, use-revolution-requ...@lists.runrev.com wrote: Two different things: The Stacks pane in the SB is used for copying separate stack files into the file that will become the standalone. The stackfiles property of a stack is a list which allows the engine to easily locate stacks which aren't in the stackfile so that you can still refer to them by just their short name in your scripts. For example, if you have a stack named Behaviors in a stack file named Behaviors.rev in a folder named Components which is in the same folder as your stack file or standalone, you can set the stackfile's property of your stack to: Behaviors,Components/Behaviors.rev ...and the engine will then know exactly where to find the stack whenever your scripts refer to a stack named Behaviors. ___ 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
Implementing a library of behavior buttons across multiple applications
I'm trying to figure out the best way to make a library of behavior buttons available to multiple applications. I originally developed the library as a substack of my application but would now like to move it to a separate .rev file and refer to it from other applications. Seems like that gives me a single maintenance point - fix any behavior problems in the library and it's automatically fixed in all applications. However, it's feeling like this isn't a practical solution. As I understand it, the behavior property of an object uses the long id of the button it refers to and I think the long id includes the operating system path to the .rev file that the button is in. Just for development purposes, I have three different folders I use - one for code and test, another for QA, and anther for the final application. SO if I set the behavior to point to my library of behaviors in the code and test folder, then move the app's .rev file to the QA folder, the behavior properties will still point to the behavior library of in the code and test folder. And so on. I'm sure there much more experienced users than me out there who have run into this problem and hoping they can share how they dealt with it. Only thing I can think of is a script that runs during installtion to go find all controls with a behavior property set and change it to the correct one. Pete Haworth http://www.mollysrevenge.com http://www.sonicbids.com/MollysRevenge http://www.myspace.com/mollysrevengeband ___ 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
