Recently, Graham Samuel wrote: >>> I've got three stacks, let's say stack 'A' whose style is topLevel, >>> and stacks 'B' and 'C' whose style is palette. The global property >>> raisepalettes is true, but despite this, if I click on 'A', it moves >>> in front of 'B' and 'C'. >>> >> >> Something else is probably going on here. It's unlikely (if not >> impossible) >> for a toplevel stack to appear above a palette stack (thus the >> reason for >> the existence of palette stacks). Either you're somehow setting >> stack 'A' >> to palette mode, or you're changing the mode of 'B' and 'C' to >> topLevel. >> >> Are you changing the modes/styles of your stacks via script? > > ... > You say that it's not impossible for a toplevel stack to appear above > a palette stack - can you give any more detail on this? I see nothing > in the RR docs.
There is nothing in the RR docs that I know of. My intent was to imply that it's *extremely* unlikely that a palette can ever be rendered above a topLevel stack in the same app (there may be some bug going on but I've yet to see anything like this in years of working with Rev/MC). I would suggest that whenever you experience what you perceive to be a topLevel stack displaying above a palette, immediate query the stack modes in the message box and see what the result is. Something like: put short name of stack 'A' && mode of stack 'A' && \ short name of stack 'B' && mode of stack 'B' && \ short name of stack 'C' && mode of stack 'C' My guess is you'll find the modes to be the same (1 or 2 = topLevel, 4 = palette). If not, you may have discovered a bug. Regards, Scott Rossi Creative Director Tactile Media, Multimedia & Design ----- E: [EMAIL PROTECTED] W: http://www.tactilemedia.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