Palette that reacts when changeing the top stack....

[David Bovill]

Thanks for the pointers. I've been battling with using the "resumeStack"
handler in a front script. It gets called everywhere including when
something is put in the message box, causing recursion so I've had to
include the following tests to get it working safely. Just started using it
today - so there may be case which still cause recursion?

on resumeStack
>     -- safety
>     if the shiftkey is "Down" then pass resumeStack
>
>     -- sent to the card of the stack clicked on
>     put the long id of the owner of the target into stackObject
>     put the mode of stackObject into stackMode
>     -- skip if it is a palette or similar
>     if stackMode > 2 then pass resumeStack
>
>     -- safety (stops messages and other stack causing recursion)
>     put the short name of stackObject into stackName
>     if char 1 to 3 of stackName = "rev" then pass resumeStack
>
>     -- do your stuff here
>     beep


>     pass resumeStack
> end resumeStack


You also have to trap for "openStack" or "preOpenStack" as opening a new
stack does not triger the "resumeStack" event.


2008/6/4 Wilhelm Sanke <sanke at hrz.uni-kassel.de>:

>
> David Bovill david at openpartnership.net wrote on
> Sat May 31, 2008:
>
>  Its been a while since I've done this... what's the best way to trap for
>> this? Do I need a front script (in case the stack blocks a message) - or
>> can
>> I intercept and pass a Rev IDE specific message?
>>
>
>
>
> and on Mon Jun 2, 2008
>
>  Yeah - and what a nightmare to debug! Not sure if it does this in Rev IDE
>> but any bug or event that causes something to be put into the messagebox -
>> triggers the resumeStack again which can then cause infinite loops - goto
>> block that....
>>
>> 2008/6/2 Mark Schonewille <m.schonewille at economy-x-talk.com>:
>>
>> > Hi david,
>> >
>> > I'd trap the resumeStack message, sometimes the (pre)openStack message,
>> in
>> > a front script.
>>
>
>
>
> Concerning the refreshing of a palette or a modeless stack when something
> in the topstack changes or when the topstack itself changes:
> three examples and hints:
>
> 1. Rev Application Browser
>
> If you select - with the pointer tool activated - a control in the topstack
> and have previously chosen the card that contains the control in the
> Application Browser, then you can "refresh" the Application Browser by
> clicking in the left window or the decorations bar of the AB. The AB will
> then hilite the line of the control (tested with Rev version 2.9).
>
> 2. The Metacard Control Browser
>
> The Control Browser of the MC IDE is more efficient in this respect. It
> will update immediately and automatically when you select a control of the
> topstack, i.e.  without need to enter the Control Browser or click on it. As
> far as I remember this is brought about by the "refresh" handler in the card
> script of the Control Browser.
>
> 3. MCBrowser and "RevBrowser"
>
> These personal tools were developed 8 years ago at a time when the
> performance of the precursor of the Application Browser was unsatisfactory
> in many respects, "RevBrowser" is not a web-browser and should therefore not
> be mistaken for the new Rev web-object.
> Quite a number of such tools have been developed by members of this list
> addressing a whole range of specific needs that are not covered by the Rev
> IDE.
>
> Both MCBrowser and RevBrowser reflect
>
> - the changing of the topstack
> - going to a different card of the topstack
> - choosing (selecting) a different control
>
> when you re-enter the Browsers (triggered by a mouseenter-handler).
>
> Have a look at the card and stack scripts of these stacks to see how this
> was implemented. Basically, it must be possible - using a routine similar to
> that ot the Metacard Control Browser - to achieve a "refresh" automatically
> without entering the browsers with the mousecursor.
> I haven't looked at the scripts myself for a longer time, so bear with me
> that you should have a look for yourself, but I use especially the McBrowser
> - as I still prefer the MC IDE over the Rev IDE for faster and more
> efficient workflow - on a regular basis with larger stacks when I need to
> change the scripts of a greater number of controls.
>
> You can get and inspect these stacks from page "Tools and Samples for
> Development" of my website
>
> <http://www.sanke.org/MetaMedia>
>
> ===========================
>
> From the text of that page:
>
> "RevBrowser":
> for "Revolution" only: The small, convenient, and fast alternative to Rev's
> "Application Browser" and "Object Browser". Includes a fast script searching
> tool that lists all found scripts lines - with the searchstring colored -
> along with the addresses of the objects. Clicking on the object address lets
> you edit the respective script.
> Stack is from 2001 and needs to be updated - there are some bugs - and
> because it is not yet able to access and edit "unplaced" groups - which you
> also cannot do with the above-mentioned Rev-IDE tools.
>
> MC-Browser:
> The Metacard version of the above "RevBrowser". It is basically an enhanced
> and refined Metacard "Control Browser" with an added fast-search function
> that lets you search all scripts of a stack. The search tool lists all found
> scripts lines - with the searchstring colored - along with the addresses of
> the objects. Clicking on the object address enables you to edit the
> respective script. (Stack is from 2001, may have some bugs, and especially
> is unable to deal with "unplaced" groups).-
>
> Best regards,
>
> Wilhelm Sanke
>
>
> _______________________________________________
> 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
>