Variable transfers Between Stacks and Sub-Stacks.

[Simon HARPER]

Can I thank everyone who responded to this. Thanks for that!


Cheers
Si.

====
Simon Harper
2.44 Kilburn Building
University of Manchester (UK)

Pri: simon.harper at manchester.ac.uk
Alt: sharper at cs.man.ac.uk


On 29 Mar 2007, at 17:18, Trevor DeVore wrote:

> On Mar 29, 2007, at 8:42 AM, Richmond Mathewson wrote:
>
>> 1. So let's have a merry drop-down button on the Main
>> Stack to change units.
>>
>> 2. on mouseUp
>>       the mouseLine
>>       if it is "inches" then
>>         do FANCY CONVERSION ROUTINE NUMBER 999
>>       end if
>>      end mouseUp
>>
>> where FANCY CONVERSION ROUTINE NUMBER 999 pushes all
>> the values contained in all the list fields on the
>> main stack and all the substacks through the required
>> algorithm to convert (say) millimetres to inches.
>
> Hi Richmond (sorry, this somehow turned into a long post),
>
> While there is nothing difficult about the example you provide  
> above, I see a broadcasting system (like the one Dave has talked  
> about) as making your code cleaner and easier to read.
>
> The above example only changes the property in once place (as is  
> common for many application preferences).  But there are some  
> scenarios where you can change a property of an object from  
> multiple locations.  For example, if I wanted to change the title  
> of an image in an image cataloging application I might have a  
> command like the following:
>
> image_setProp theImageObject, "title", theNewTitle
>
>
> -- Without Broadcasting --
>
> Using your technique above you might then add a second call which  
> updated the title of the image anywhere it appeared in the program  
> (maybe in a thumbnail window and an editor window) so you end up  
> with something like this anywhere you want to change the title:
>
> image_setProp theImageObject, "title", theNewTitle
> UpdateImageAnywhereItAppearsInProgram theStepControl
>
>
> -- With Broadcasting --
>
> Using broadcasting, you could register the thumbnail window and the  
> editor window to receive messages whenever the "title" property of  
> a image was updated using a handler that might be defined as follows:
>
> object_addPropertyListener pObject, pProperties, pTargetObject,  
> pMessage
>
> And in practice might be called like this when a new image was  
> created:
>
> object_addPropertyListener theNewImageObject, "title", the long id  
> of stack "ThumbnailViewer", "ImagePropertyUpdated"
> object_addPropertyListener theNewImageObject, "title", the long id  
> of stack "Editor", "ImagePropertyUpdated"
>
> Now in my code I can just set the image title from anywhere I would  
> like (using image_setProp) and I know that it will be updated  
> everywhere in the program.  I don't have to remember to set the  
> title and then call another function to update windows everywhere.
>
>
> -- Implementing Broadcasting --
>
> Some development environments, like Flash, have built-in  
> broadcasting support.  Revolution does not so you end up having to  
> create your own libraries to handle it.  While this is a little  
> more effort at first to write the library it really pays off for  
> folks who prefer the broadcasting approach.
>
> For example, in the "image_setProp" handler (which can be used to  
> set any number of properties) you would then have the following  
> call near the end of it's definition which would handle  
> broadcasting the changed property to any "listeners":
>
> on image_setProp pControlReference, pProperty, pValue
>     ## DO WHATEVER TO STORE PROPERTY
>     ....
>
>     ## BROADCAST PROPERTY CHANGE
>     object_broadcastPropertyChange pObject, pProperties
> end image_setProp
>
> In the end you are getting the same behavior.  I happen to think  
> broadcasting is a cleaner way of approaching the problem and use  
> that approach in my projects as well.
>
>
> -- 
> Trevor DeVore
> Blue Mango Learning Systems
> www.bluemangolearning.com    -    www.screensteps.com
> trevor at bluemangolearning.com
>
>
> _______________________________________________
> use-revolution mailing list
> use-revolution at lists.runrev.com
> Please visit this url to subscribe, unsubscribe and manage your  
> subscription preferences:
> http://lists.runrev.com/mailman/listinfo/use-revolution