What is the best practice for opening a stack window and having it stay on top? I find that often when I open a new stack window programmatically, the window opens on top, but then the old stack (that was exciting the code) pops back on top. It's seems like when the handler that opens the 2nd stack finishes it returns that stack to the top.
I've tried setting the 2nd window (that gets opened) to be a palette, but that seems like overkill.
Thanks.
_Chuck
Best practice for getting a window on top
Moderators: FourthWorld, heatherlaine, Klaus, kevinmiller
Re: Best practice for getting a window on top
Hi.
Not sure what you mean. If a handler in one stack opens (or goes to) another, it will stay there even if more code is executed. Try this. It will be fast and fun. Make two stacks. Name the first "S1" and the second "S2" Put a button and a field on stack "S1", and this in its script:
Craig Newman
Not sure what you mean. If a handler in one stack opens (or goes to) another, it will stay there even if more code is executed. Try this. It will be fast and fun. Make two stacks. Name the first "S1" and the second "S2" Put a button and a field on stack "S1", and this in its script:
Code: Select all
on mouseUp
repeat 10
put random(999) into fld 1
wait 5
end repeat
go stack "S2"
repeat 10
put any char of "ABCDEFG" into fld 1 of stack "S1"
wait 5
end repeat
put "It's 10PM. Do you know where your stack is?" into fld 1 of stack "S1"
answer the topstack
end mouseUp
Re: Best practice for getting a window on top
Thanks. I understand that is the way it is supposed to work, but I find that sometimes the second stack opens behind the original one (or opens in front, but then the original moves in front).
Here's a stack that demonstrates the inconsistent performance. There is a little "simulation animation" that runs. When the user clicks the "continue" button, I want to stop the animation and open a new stack window. There are 2 versions (cards 2 & 3 of the stack).
On card 2 the simulation is started and run at the card script level. When the animation ends and the new stack opened, the new stack appears behind the original stack (the bad performance I don't like). The user is brought to card 3 of the original stack, rather than to the newly opened stack.
On card 3 the simulation is started and run with a button. Here the performance is what I expect: The user gets taken to the new stack.
So my conclusion is that something about the card handlers finishing up must be bringing control back to the original stack. This has been nagging at me for awhile...
Here's a stack that demonstrates the inconsistent performance. There is a little "simulation animation" that runs. When the user clicks the "continue" button, I want to stop the animation and open a new stack window. There are 2 versions (cards 2 & 3 of the stack).
On card 2 the simulation is started and run at the card script level. When the animation ends and the new stack opened, the new stack appears behind the original stack (the bad performance I don't like). The user is brought to card 3 of the original stack, rather than to the newly opened stack.
On card 3 the simulation is started and run with a button. Here the performance is what I expect: The user gets taken to the new stack.
So my conclusion is that something about the card handlers finishing up must be bringing control back to the original stack. This has been nagging at me for awhile...
Re: Best practice for getting a window on top
oops. looks like I didn't attach the stack to the previous post. I can't attach a .livecode file? and when I zip it I get told it exceeds the 256 kb limit. so much for attachments.