Richard Gaskin <[EMAIL PROTECTED]> wrote > > Is there another function or way to determine the "effective" topstack > > irrespective of the mode the stack has? > > > get the windows > > -- Richard Gaskin Fourth World Media Corporation Developer of WebMerge 2.2: Publish > any database on any site > >
Thanks for your response, Richard, but I had already tried that function and mentioned it in my post in the paragraph about workarounds. "Jeanne A. E. DeVoto" <[EMAIL PROTECTED]> wrote: > Here's a function: > > function activeWindow > -- excludes modal dialogs, palettes, menus > repeat for each line thisWindow in the openStacks > if the mode of stack thisWindow < 4 then return thisWindow > end repeat > return empty > end activeWindow > > The windows function (aka the openStacks function) is documented in the > Transcript dictionary. > Thanks, too, for your response and the alternate function script. I see now that there is no direct function like the "topstack", but that we have to script a filtering function as I had indicated for my workarounds. On closer inspection (mea culpa, one should look harder and not be too rash) I find that the "windows" function is indeed explained in the Transcript Dictionary although not as a separate entry, but as an unobtrusive synonym in the "openstacks" entry.- The "openstacks", "the stacks", and "the windows" functions, unfortunately, *sometimes* produce what I called "unexpected behavior" in one of my stacks. This was the reason why I was looking for another, but "clean" function to get the "effective topstack". I am not saying that these functions cause this unexpected behavior, but they surely contribute to it in the context of my stack and presumably only on Windows. Apart from what I already mentioned - modal dialogs not immediately closing despite an following "wait x milliseconds" line - parts of the stack suddenly become transparent for a moment. I am trying find out what coincidences may cause this behavior. I remember someone mentioned this "partial transparency" of a stack caused by the hyperlink style recently, either on this or the Metacard list. Regards, Wilhelm Sanke _______________________________________________ use-revolution mailing list [EMAIL PROTECTED] http://lists.runrev.com/mailman/listinfo/use-revolution
