19 Replies Latest reply on Jan 7, 2008 3:46 PM by Newsgroup_User

    MIAW WindowType - preventing pass-through clicks, but non-modal?

    Level 7
      Other than the 10 types listed in the Help files, does anyone know about any
      other window types? What I'm specifically looking for is like a tool
      palette - which floats over the stage, but if you click on it, the clicks do
      not pass through the MIAW to the stage below it. So far, the only way I
      know to do that is to make it a modal dialog box, which is NOT what I want,
      because I want to still be able to click on things on the stage, just not if
      they're directly behind the tool palette.

      Alternatively, is there a way to make sure all mouse-clicks within a MIAW do
      NOT pass through to the stage behind it? I'm using type 4, "Movable window
      without size box or zoom box", which seems to be the closest one to what I
      want, but I need to stop those pass-through clicks from messing up the
      stage...


        • 1. Re: MIAW WindowType - preventing pass-through clicks, but non-modal?
          Level 7
          You must be using an older version than MX 2004 and should perhaps say
          so when posting, as the assumption is more likely to be that you're
          using the "current" version.
          You will probably need to check, in all your stage's mouseDown/Up
          handlers, whether the MIAW rect is under the mouse when the handler runs
          and bail out if so.
          You might also want to test the trial version of MX 2004 to see whether
          window handling is an improvement. Be aware that lots of changes have
          been made to MIAWs with the later version compared with MX and earlier.
          • 2. Re: MIAW WindowType - preventing pass-through clicks, but non-modal?
            Level 7
            > You must be using an older version than MX 2004

            I'm only one behind - MX, not 2004. Is it really that different one version
            later?


            • 3. Re: MIAW WindowType - preventing pass-through clicks, but non-modal?
              Level 7
              > Is it really that different one version later?

              Yes. Download the trial version and see for yourself whether the newer
              window handling improves your situation.
              • 4. Re: MIAW WindowType - preventing pass-through clicks, but non-modal?
                Level 7
                > Yes. Download the trial version and see for yourself whether the newer
                > window handling improves your situation.

                Well, I've got the trial version and tried it out, and it behaves exactly
                the same way. Is there some new code to go along with this that I need to
                use to make it work properly? The "windowType" keyword no longer even shows
                in the Help docs, I'm assuming the code has been updated to allow more
                options? I read through every page under the MIAW header, and none of them
                specify what code you need to change window properties.

                I tried setting the type = #tool, but that's exactly the same as the old
                windowType = 4 that I was using before.. I still get click-throughs if the
                toolbar is over the stage. #dialog has no clickthroughs, but I can't click
                on the stage at all because it's modal. #document is the worst in that it
                allows both clickthroughs and resize/zoom. And those seem to be the only
                options. What am I missing here?


                • 5. Re: MIAW WindowType - preventing pass-through clicks, but non-modal?
                  Level 7
                  You can try to put down an invisible sprite on the MIAW to absorb the
                  click with a script like this:

                  on mouseDown me
                  dontPassEvent
                  end

                  on mouseUp me
                  dontPassEvent
                  end
                  • 6. Re: MIAW WindowType - preventing pass-through clicks, but non-modal?
                    Level 7
                    > You can try to put down an invisible sprite on the MIAW to absorb the
                    > click with a script like this:

                    Problem with that is that the MIAW is movable, so the sprite would have to
                    move with it. I tried working with something like that, but I still always
                    wound up getting one stray click every time I moved the MIAW, since the
                    window-movement happens outside of the movie's code, and the mouse events
                    register before the code that moves the sprite. Now in some cases you could
                    bet on that stray click not being over a clickable sprite, but that doesn't
                    work in my case, since every pixel on the stage is covered with clickable
                    sprites. (Tiles for a game.)

                    I worked up something like Sean's suggestion:

                    if (the mouseLoc + point(the stage.rect.left,the
                    stage.rect.top)).inside(window("EditorMenu").rect) = FALSE then
                    ...etc.

                    Which does the trick, but I have to have it on every single mouse event on
                    the stage, and it seems like a hack-solution, far more code than necessary
                    to do something which by all rights should be the default behavior. (I
                    can't imagine any instance in which you'd WANT to be able to click through
                    an MIAW. I imagine there are probably some, but you'd think those'd be the
                    exception, not the rule.)


                    • 7. Re: MIAW WindowType - preventing pass-through clicks, but non-modal?
                      Level 7

                      "Darrel Hoffman" <no.address@all.com> wrote in message
                      news:fljs2m$h48$1@forums.macromedia.com...
                      >> You can try to put down an invisible sprite on the MIAW to absorb
                      >> the click with a script like this:
                      >
                      > Problem with that is that the MIAW is movable, so the sprite would
                      > have to move with it. I tried working with something like that, but
                      > I still always wound up getting one stray click every time I moved
                      > the MIAW, since the window-movement happens outside of the movie's
                      > code, and the mouse events register before the code that moves the
                      > sprite. Now in some cases you could bet on that stray click not
                      > being over a clickable sprite, but that doesn't work in my case,
                      > since every pixel on the stage is covered with clickable sprites.
                      > (Tiles for a game.)
                      >
                      > I worked up something like Sean's suggestion:
                      >
                      > if (the mouseLoc + point(the stage.rect.left,the
                      > stage.rect.top)).inside(window("EditorMenu").rect) = FALSE then
                      > ...etc.
                      >
                      > Which does the trick, but I have to have it on every single mouse
                      > event on the stage, and it seems like a hack-solution, far more code
                      > than necessary to do something which by all rights should be the
                      > default behavior. (I can't imagine any instance in which you'd WANT
                      > to be able to click through an MIAW. I imagine there are probably
                      > some, but you'd think those'd be the exception, not the rule.)

                      Hi,
                      can you not use a movieScript with a mouseUp/mouseDown handler?
                      Moviescripts are called before spriteScripts / behaviours, so you can
                      intercept them there.

                      Or do I miss something?

                      Richard.


                      • 8. Re: MIAW WindowType - preventing pass-through clicks, but non-modal?
                        Level 7
                        > Hi,
                        > can you not use a movieScript with a mouseUp/mouseDown handler?
                        > Moviescripts are called before spriteScripts / behaviours, so you can
                        > intercept them there.
                        >
                        > Or do I miss something?

                        Unfortunately, I'm pretty sure that Windows-events, such as moving a MIAW,
                        which is not controlled by any scripts in Director but rather by the OS,
                        take precedence over all scripted events in a Director movie, including
                        Moviescripts. At least that's what appears to be happening. Doesn't matter
                        where I put this code, moving the window around occurs before any code I can
                        execute. At any rate, you can't use mouseWithin, mouseEnter, and mouseLeave
                        events in a Moviescript, because they're all sprite-specific. And I
                        actually have a majority of my code happen on mouseWithin events, e.g.:

                        on mouseWithin me
                        if the mouseDown then etc.

                        This allows the user to click and drag over multiple sprites and affect all
                        of them, rather than having to individually click them one by one. (Since
                        this is a level editor, that's a MAJOR timesaver.)


                        • 9. Re: MIAW WindowType - preventing pass-through clicks, but non-modal?
                          Level 7
                          That is completely the problem right there. Since the mouse is in fact
                          within the sprite, then it is sensible that the code would run. If you
                          use mouseDown and mouseUp events instead (which is the more common way
                          of dealing with the mouse), then you would not have these problems. The
                          issue is specific to your programming style. You are telling the
                          computer to do something when the mouse is within the sprite, but you
                          don't in fact want that to happen all the time. In order to fix the
                          problem, you will need to put some conditional inside of your script to
                          see if the MIAW is in the way. You can use windowPresent() to see if a
                          MIAW is open and check it's coordinates to make sure that it is not over
                          the mouse. It is terribly tedious, but that is the only way I know of
                          to fix it, apart from not using mouseWithin to deal with your mouse
                          events.

                          None of this will happen if you just use on mouseDown and on mouseUp for
                          your mouse handling.
                          • 10. Re: MIAW WindowType - preventing pass-through clicks, but non-modal?
                            Level 7

                            "Darrel Hoffman" <no.address@all.com> wrote in message
                            news:flmfdk$dku$1@forums.macromedia.com...
                            >> Hi,
                            >> can you not use a movieScript with a mouseUp/mouseDown handler?
                            >> Moviescripts are called before spriteScripts / behaviours, so you
                            >> can intercept them there.
                            >>
                            >> Or do I miss something?
                            >
                            > Unfortunately, I'm pretty sure that Windows-events, such as moving a
                            > MIAW, which is not controlled by any scripts in Director but rather
                            > by the OS, take precedence over all scripted events in a Director
                            > movie, including Moviescripts. At least that's what appears to be
                            > happening. Doesn't matter where I put this code, moving the window
                            > around occurs before any code I can execute. At any rate, you can't
                            > use mouseWithin, mouseEnter, and mouseLeave events in a Moviescript,
                            > because they're all sprite-specific. And I actually have a majority
                            > of my code happen on mouseWithin events, e.g.:
                            >
                            > on mouseWithin me
                            > if the mouseDown then etc.
                            >
                            > This allows the user to click and drag over multiple sprites and
                            > affect all of them, rather than having to individually click them
                            > one by one. (Since this is a level editor, that's a MAJOR
                            > timesaver.)

                            I think I am really missing the point here... I never had any of the
                            problems you are describing with dragging windows around, or events
                            getting to the stage...

                            The click and drag that goes with the moving of a window should be
                            intercepted by the OS, and not ever be passed to the application. Only
                            AFTER moving, the application gets sent a message about the new
                            position of that window. Those are system messages, not user handled
                            messages.

                            What OS and version are you on?

                            I also dont understand why you would check for "mouseDown" in a
                            mouseWithin handler. It does not intercept the mouseDown event, it
                            just checks for a condition.
                            That is exactly what "on mouseDown" is for...
                            Maybe add an empty "on mouseDown" in every behaviour to stop the
                            event?

                            Is there more to this than you have shown us so far?

                            Richard.



                            • 11. Re: MIAW WindowType - preventing pass-through clicks, but non-modal?
                              Level 7
                              The point of checking for MouseDown inside a MouseWithin handler is that you
                              can click and "paint" tiles over any number of sprites, without having to
                              release the mouse button and click each sprite individually. If I put
                              everything into MouseUp/MouseDown handlers, then you'd have to click each
                              sprite one by one in order to change the tiles, which is incredibly tedious
                              compared the smooth click-and-drag method I'm using.

                              As I've said, checking to see if the mouse is within the rect of the MIAW
                              *does* prevent clickthroughs. In other words, I do have a working solution
                              to my problem. I just still think it's far more code than should be
                              necessary to do what should by all rights happen by default, especially
                              since I have to incorporate this same code into several different mouse
                              events in a bunch of different behaviors. (It will be even worse if I at
                              some point decide to have more than one tool palette MIAW up at the same
                              time for some reason, since I'd have to check for each of them, and then
                              check *within* each of them as well in case they overlap eachother...)

                              We kind of got sidetracked with the whole idea of a moving sprite underneath
                              the MIAW to catch stray mouse events - a technique which doesn't work 100%
                              because moving the MIAW causes a stray mouse-click when you release it.

                              I just wish there were some default setting for MIAW's which prevented
                              clickthroughs automatically. It's pretty much an aesthetic thing now, since
                              I have a working solution, but I don't like ugly code (even if nobody but me
                              will ever see it), and I wish there was a better way to do it. Just seems
                              like it should be the default behavior. Think of any other program you've
                              seen. Indeed, since we all know Director, think of that. Say you've got
                              the Score window and the Cast window and the Script window and
                              who-knows-what-else all open at once, and they're all overlapping on your
                              screen. When you click on one, only the one on top responds. This is what
                              you expect when you click on something in any program. You'd run into all
                              kinds of problems if the ones underneath also responded to your clicks (or
                              any other mouse events for that matter). This is basically the same thing
                              I'm trying to do with my little tool palette, but it seems you have to write
                              a whole bunch of scripts just to make that happen? That just doesn't seem
                              right to me.

                              Anyhow, thanks for your suggestions everyone. And if anyone knows a way to
                              make MIAW's do this automatically, please let me know.


                              • 12. Re: MIAW WindowType - preventing pass-through clicks, but non-modal?
                                Level 7

                                "Darrel Hoffman" <no.address@all.com> wrote in message
                                news:fln0nb$c5$1@forums.macromedia.com...
                                > The point of checking for MouseDown inside a MouseWithin handler is
                                > that you can click and "paint" tiles over any number of sprites,
                                > without having to release the mouse button and click each sprite
                                > individually. If I put everything into MouseUp/MouseDown handlers,
                                > then you'd have to click each sprite one by one in order to change
                                > the tiles, which is incredibly tedious compared the smooth
                                > click-and-drag method I'm using.
                                >
                                > As I've said, checking to see if the mouse is within the rect of the
                                > MIAW *does* prevent clickthroughs. In other words, I do have a
                                > working solution to my problem. I just still think it's far more
                                > code than should be necessary to do what should by all rights happen
                                > by default, especially since I have to incorporate this same code
                                > into several different mouse events in a bunch of different
                                > behaviors. (It will be even worse if I at some point decide to have
                                > more than one tool palette MIAW up at the same time for some reason,
                                > since I'd have to check for each of them, and then check *within*
                                > each of them as well in case they overlap eachother...)
                                >
                                > We kind of got sidetracked with the whole idea of a moving sprite
                                > underneath the MIAW to catch stray mouse events - a technique which
                                > doesn't work 100% because moving the MIAW causes a stray mouse-click
                                > when you release it.
                                >
                                > I just wish there were some default setting for MIAW's which
                                > prevented clickthroughs automatically. It's pretty much an
                                > aesthetic thing now, since I have a working solution, but I don't
                                > like ugly code (even if nobody but me will ever see it), and I wish
                                > there was a better way to do it. Just seems like it should be the
                                > default behavior. Think of any other program you've seen. Indeed,
                                > since we all know Director, think of that. Say you've got the Score
                                > window and the Cast window and the Script window and
                                > who-knows-what-else all open at once, and they're all overlapping on
                                > your screen. When you click on one, only the one on top responds.
                                > This is what you expect when you click on something in any program.
                                > You'd run into all kinds of problems if the ones underneath also
                                > responded to your clicks (or any other mouse events for that
                                > matter). This is basically the same thing I'm trying to do with my
                                > little tool palette, but it seems you have to write a whole bunch of
                                > scripts just to make that happen? That just doesn't seem right to
                                > me.
                                >
                                > Anyhow, thanks for your suggestions everyone. And if anyone knows a
                                > way to make MIAW's do this automatically, please let me know.

                                Darrel,
                                out of all the possible ways to do what you want, you have probably
                                picked the worse.
                                Now you run into trouble, of course.

                                First:
                                Read up on the way events are processed in Director, and passed or not
                                passed from object to object.

                                Second:
                                Did you actually READ what I wrote? You just keep repeating the same
                                things that dont make sense...
                                The mouseDown event is not the problem, the problem is that you check
                                for a mouseDown STATE, not handle a mouseDown EVENT.
                                You can change your code easily to provide for this and have the same
                                result.

                                Third:
                                When mouseClicks are somehow not intercepted in the MIAW, then handle
                                them yourself in the MIAW.


                                I agree with Mike that it is your approach to the problem that creates
                                this complexity.
                                If you stick to handling events in the way Director gives them to you,
                                you will not have those strange things.

                                good luck,
                                Richad.



                                • 13. Re: MIAW WindowType - preventing pass-through clicks, but non-modal?
                                  Level 7
                                  > Moviescripts are called before spriteScripts / behaviours

                                  No, they aren't.
                                  • 14. Re: MIAW WindowType - preventing pass-through clicks, but non-modal?
                                    Level 7
                                    > Anyhow, thanks for your suggestions everyone. And if anyone knows a way to
                                    > make MIAW's do this automatically, please let me know.

                                    I don't think you're going to find an "automatically". As you later
                                    described, your problem is due to checking for the mouse being /within/
                                    a sprite as opposed to whether it's clicked on or not. Unfortunately the
                                    "within" test ignores whether there's another window sitting over the
                                    top of the sprite.
                                    I'm with Mike's solution:
                                    --
                                    on mouseWithin me
                                    if windowPresent("window_name") then exit
                                    -- whatever else you need to do
                                    -- ...
                                    end

                                    • 15. Re: MIAW WindowType - preventing pass-through clicks, but non-modal?
                                      Level 7

                                      "Sean Wilson" <webforumsuser@macromedia.com> wrote in message
                                      news:flp2f4$5o5$1@forums.macromedia.com...
                                      >> Moviescripts are called before spriteScripts / behaviours
                                      >
                                      > No, they aren't.

                                      Oops! You are right here!
                                      Did I really write that? :-S

                                      **grumble* .... :(

                                      Richard.


                                      • 16. Re: MIAW WindowType - preventing pass-through clicks, but non-modal?
                                        Level 7
                                        > I think I am really missing the point here... I never had any of the
                                        > problems you are describing with dragging windows around, or events
                                        > getting to the stage...
                                        >
                                        > The click and drag that goes with the moving of a window should be
                                        > intercepted by the OS, and not ever be passed to the application. Only
                                        > AFTER moving, the application gets sent a message about the new position
                                        > of that window. Those are system messages, not user handled messages.

                                        I don't know, but I always get one stray click after moving the window,
                                        unless I tell the scripts to ignore clicks if they're within the MIAW's
                                        rect.

                                        > What OS and version are you on?

                                        XP Pro and MX 2004 (Currently still on trial version, but had the same
                                        problem on MX full version.)

                                        > I also dont understand why you would check for "mouseDown" in a
                                        > mouseWithin handler. It does not intercept the mouseDown event, it just
                                        > checks for a condition.
                                        > That is exactly what "on mouseDown" is for...
                                        > Maybe add an empty "on mouseDown" in every behaviour to stop the event?

                                        If I use the mouseDown event, then the user will have to click repeatedly
                                        for every single tile they want to place. Using a mouseDown condition
                                        within a mouseWithin means you can click once, hold, and paint tiles over a
                                        large area, which is MUCH less tedious. I could do the same thing I suppose
                                        using a mouseEnter event, but then I'd need the same code on both the
                                        mouseEnter and the mouseDown (in case the user *doesn't* want to paint
                                        multiple sprites), whereas my way, I only need to have the code once. Sure,
                                        it's running the code more than it needs to if you hold the mouse down for a
                                        while, but it runs fast enough that this isn't a serious problem. (It's
                                        only the level editor, anyhow, not the actual game.)


                                        • 17. Re: MIAW WindowType - preventing pass-through clicks, but non-modal?
                                          Level 7
                                          > I don't think you're going to find an "automatically". As you later
                                          > described, your problem is due to checking for the mouse being /within/ a
                                          > sprite as opposed to whether it's clicked on or not. Unfortunately the
                                          > "within" test ignores whether there's another window sitting over the top
                                          > of the sprite.
                                          > I'm with Mike's solution:
                                          > --
                                          > on mouseWithin me
                                          > if windowPresent("window_name") then exit
                                          > -- whatever else you need to do
                                          > -- ...
                                          > end

                                          That's no good at all, because when you're in the Level Editor, the window
                                          is ALWAYS present, so the code will never work...


                                          • 18. Re: MIAW WindowType - preventing pass-through clicks, but non-modal?
                                            Lukewig Level 1
                                            >> on mouseWithin me
                                            >> if windowPresent("window_name") then exit
                                            >> -- whatever else you need to do
                                            >> -- ...
                                            >> end

                                            >That's no good at all, because when you're in the Level Editor, the window
                                            >is ALWAYS present, so the code will never work...

                                            Hi,

                                            you could try filtering mouseEvents by checking that the script is running in the active window. Then you would only need to add one line of code to all your mouse event handlers:

                                            on mouseWithin (me)
                                            if NOT ThisWindowActive() then return
                                            --- do whatever
                                            end


                                            Where the 'ThisWindowActive' function looks like this (in each movie)

                                            on ThisWindowActive()
                                            return (_player.activeWindow = "Whatever this window is")
                                            end

                                            -- Luke
                                            • 19. Re: MIAW WindowType - preventing pass-through clicks, but non-modal?
                                              Level 7

                                              "Darrel Hoffman" <no.address@all.com> wrote in message
                                              news:flu5me$nfb$1@forums.macromedia.com...
                                              >> I think I am really missing the point here... I never had any of
                                              >> the problems you are describing with dragging windows around, or
                                              >> events getting to the stage...
                                              >>
                                              >> The click and drag that goes with the moving of a window should be
                                              >> intercepted by the OS, and not ever be passed to the application.
                                              >> Only AFTER moving, the application gets sent a message about the
                                              >> new position of that window. Those are system messages, not user
                                              >> handled messages.
                                              >
                                              > I don't know, but I always get one stray click after moving the
                                              > window, unless I tell the scripts to ignore clicks if they're within
                                              > the MIAW's rect.
                                              >
                                              >> What OS and version are you on?
                                              >
                                              > XP Pro and MX 2004 (Currently still on trial version, but had the
                                              > same problem on MX full version.)
                                              >
                                              >> I also dont understand why you would check for "mouseDown" in a
                                              >> mouseWithin handler. It does not intercept the mouseDown event, it
                                              >> just checks for a condition.
                                              >> That is exactly what "on mouseDown" is for...
                                              >> Maybe add an empty "on mouseDown" in every behaviour to stop the
                                              >> event?
                                              >
                                              > If I use the mouseDown event, then the user will have to click
                                              > repeatedly for every single tile they want to place.


                                              What is the problem with something like:

                                              on mouseDown me

                                              me.paintTile(this_tile)

                                              while (the stillDown)
                                              sendSprite((the rollOver), #paintTile(this_tile))
                                              end

                                              end mouseDown

                                              (Not checked for functionality, Pseudo code)

                                              Richard.