Only thing I can think of is if the MIAW's text field has focus, even if
the movie is out of focus, Director *might* try to deliver the event there
anyway.
Generally Director attempts to deliver events first to the sprite, then to
the castmember, the frame, and the movie.
I don't know what the rule is if a MIAW which is not the activeWindow has a
text field with focus. It's conceivably possible that Director would
attempt to delivery the keyUp event to that field ANYWAY, if it's the only
active text field in the system.
Unlike a mouseclick, which has a defined destination, a keyUp is more of a
floater event, and doesn't have a destination sprite unless you have an
active editable text field. If you do, I would say that it wouldn't
necessarily surprise me if Director chose to deliver the event to that
field, even if its movie wasn't in focus. I would expect that Director
would limit it to the active movie, but maybe not - I've seen other
parallels in the system - for instance a mouse click that is clicked on
either the MIAW or the stage falls through to the window below, since
there's nothing on the active window to pick it up.
I've seen that behavior often enough, and though I've never tried to sit
down and test it, it might actually be more like:
1) See if you can deliver it to the sprite
2) See if you can deliver it to the castmember
3) See if you can deliver it to the frame
4) See if you can repeat steps 1..3 on the other open windows
5) See if you can deliver it to the movie
Again, I don't know that it specifically does that, as I usually architect
around it, but I probably work around it for that very reason, and I just
forgot why by now. I wouldn't be surprised if it works that way - could be.
- Tab
At 04:42 PM 6/23/01 +0200, Michael von Aichberger wrote:
>Hi Tab, thanks for answering.
>
> > particularly since B is supposed to launch A, so how
>is it that the handlers run in A when you start b?
>
>A is in front of B and the keyboardfocussprite is a sprite in A
>
>(B calls A with this Lingo:
>
>wMain.fileName = A
> moveToFront wMain
> tell wMain
> go to frame targetFrame
> end tell
>)
>
> > Generally, a keyUp handler on a sprite doesn't mean much unless that
>sprite
>is a text field ...
>
>You are right. It IS a text field.
>
> > By clicking on the stage or sprite of one of your movies, you're changing
>the focus to
>that movie.
>
>Correct, but clicking on some part in movie A can't change the focus to
>another movie as A. So why don't keyUp handlers respond anymore, if they did
>before that click? There are no other movies than A and B. None of them is
>getting the keyUp at this particular moment, I first have to click on B and
>then on A again - strange! And: If mouse driven operations work in A, A must
>have the focus, no? So why do mouseUps work in A while at the same time
>keyUps don't work?
>
>It's frustrating!
>Michael von Aichberger
[To remove yourself from this list, or to change to digest mode, go to
http://www.penworks.com/LUJ/lingo-l.cgi To post messages to the list,
email [EMAIL PROTECTED] (Problems, email [EMAIL PROTECTED])
Lingo-L is for learning and helping with programming Lingo. Thanks!]
