bug report: mousestate/textbox/numberbox


    Oct 30 2006 | 9:13 pm
    Summary:
    When the focus is taken away from a mousestate object via clicking on a textbox object, the mousestate seems to continue to activate even though it doesn't display visible evidence itself; somehow it still reports clicks, causing the output from a numberbox to be different than the number that it currently displays.
    Steps to Reproduce:
    Follow the instructions in the following patch.
    Expected Results:
    When the textbox has the focus, the big numberbox should print out the number it is displaying.
    Actual Results:
    The big numberbox prints out the number that would have been sent to it via a mouseclick being registered by the mousestate object... even though it doesn't display this number in the patch.
    Regression:
    tested on MacBook Pro OS X 10.4.8, MaxMSP 4.5.7 and 4.6.2
    Notes:
    I'm trying to build a quicktime movie annotation system, in which, first, a mouse click outside of a text box registers the current time, and second, clicking on the textbox allows a description to be entered for that time; but the mousestate seems to capture the click on the textbox, even though it doesn't register visibly, making it impossible to capture the correct time for the annotation.
    max v2;

    • Oct 31 2006 | 10:19 am
      Perry Hoberman wrote:
      > Summary:
      > When the focus is taken away from a mousestate object via clicking on a textbox object, the mousestate seems to continue to activate even though it doesn't display visible evidence itself; somehow it still reports clicks, causing the output from a numberbox to be different than the number that it currently displays.
      Wow, confirmed on a Powerbook PPC 4.6.2
      it seems to be either a bug in the print object or something internal to
      Max itself... scary...
      Stefan
      --
      Stefan Tiedje------------x-------
      --_____-----------|--------------
      --(_|_ ----|-----|-----()-------
      -- _|_)----|-----()--------------
      ----------()--------www.ccmix.com
    • Oct 31 2006 | 10:34 am
      >
      >> Summary:
      >> When the focus is taken away from a mousestate object via clicking on
      >> a textbox object, the mousestate seems to continue to activate even
      >> though it doesn't display visible evidence itself; somehow it still
      >> reports clicks, causing the output from a numberbox to be different
      >> than the number that it currently displays.
      >
      > Wow, confirmed on a Powerbook PPC 4.6.2
      > it seems to be either a bug in the print object or something internal
      > to Max itself... scary...
      >
      > Stefan
      >
      Same here Powerbook PPC 4.5.7
      Leo
    • Oct 31 2006 | 10:42 am
      I can confirm this behaviour on Max 4.6.2 on a 17" Macbook Pro on OSX 10.4.8, however, it's not quite what it seems....
      The issue here is not to do with the textbox taking focus away from mousestate (which it doesn't). It's that whilst the mouse is down in the textbox, no other graphical objects update, although they send their messages as expected. When you look at the messages coming out of each object with [print] you see that the behaviour is exactly the same wherever you click in the patch (except for drawing).
      If you connect a button to mousestate you will see it flash only on mouseup fo instance. You can also see this behaviour by connecting the qmetro in the patch directly to the toggle (without the mousestate), so that the numberbox is updated automatically. Holding the mouse in the textbox will prevent graphical updates in the patch, but the max window will still update at the same rate. You can see these things in the patch below.
      Anyway, the point is that the issue is that whilst the mouse is down in the textbox graphical updates are stopped in the rest of the patch, not anything to do with focus. I believe that the [mousestate] object will report regardless of other objects responding and this means you'll need a different solution for your problem.
      Regards,
      Alex
    • Oct 31 2006 | 11:00 am
      Having thought about this I see two relatively straightforward solutions. The first is very easy, and is to have a button to store the time, then use the textbox to name it.
      However, if you really want to be able to click anywhere on the screen other than the textbox to store the time you can filter the mouse button info from [mousestate] by testing the position info from the same object to see whether the mouse is in the textbox or not. To do this first send the "mode 1" message to the object to get patcher relative co-ordinates. The patch below will do this, only producing a bang when the mouse is clicked outside of the box (100,120)(100,120). You'll need to change the co-ordinates to reflect the position of your textbox in the patch (and then not change it!) but it would work....
      Alex
    • Oct 31 2006 | 5:52 pm
      thanks for sparing a few braincycles on this Alex, it's all making
      much more sense to me now, and your suggestions for alternative
      solutions are helpful
      it was just a bit of a shock to see that numberbox going all schizo on me
      and I have to admit that textbox's ability to stop graphical updates
      (while not grabbing focus) still makes my brain hurt
      but I can live with that
      pH
      >Having thought about this I see two relatively straightforward
      >solutions. The first is very easy, and is to have a button to store
      >the time, then use the textbox to name it.
      >
      >However, if you really want to be able to click anywhere on the
      >screen other than the textbox to store the time you can filter the
      >mouse button info from [mousestate] by testing the position info
      >from the same object to see whether the mouse is in the textbox or
      >not. To do this first send the "mode 1" message to the object to get
      >patcher relative co-ordinates. The patch below will do this, only
      >producing a bang when the mouse is clicked outside of the box
      >(100,120)(100,120). You'll need to change the co-ordinates to
      >reflect the position of your textbox in the patch (and then not
      >change it!) but it would work....
      >
      >Alex
      >
      >#P button 675 708 15 0;
      >#P window setfont "Sans Serif" 9.;
      >#P window linecount 1;
      >#P newex 675 679 32 196617 sel 1;
      >#P newex 675 655 27 196617 ||;
      >#P newex 889 627 179 196617 if $i1 < 100 || $i1 > 120 then 1 else 0;
      >#P newex 675 625 182 196617 if $i1 < 100 || $i1 > 120 then 1 else 0;
      >#P newex 675 601 224 196617 unpack;
      >#P newex 694 405 48 196617 loadbang;
      >#P newex 675 545 32 196617 sel 1;
      >#P newex 675 574 70 196617 zl reg;
      >#P newex 708 545 39 196617 pack;
      >#P newex 651 381 86 196617 loadmess mode 1;
      >#P newex 694 428 52 196617 metro 20;
      >#P newex 694 460 66 196617 mousestate;
      >#P connect 8 0 10 0;
      >#P connect 10 0 11 0;
      >#P fasten 9 0 10 1 894 649 697 649;
      >#P connect 7 1 9 0;
      >#P connect 7 0 8 0;
      >#P connect 4 0 7 0;
      >#P connect 11 0 12 0;
      >#P connect 1 0 0 0;
      >#P connect 6 0 1 0;
      >#P connect 5 0 4 0;
      >#P fasten 0 0 5 0 699 511 680 511;
      >#P fasten 3 0 4 1 713 567 740 567;
      >#P fasten 0 2 3 1 727 511 742 511;
      >#P connect 0 1 3 0;
      >#P fasten 2 0 0 0 656 452 699 452;
      >#P window clipboard copycount 13;
      >
      --
      PERRY HOBERMAN
      Visiting Professor, Interactive Media Division
      School of Cinema-Television, LUC310a
      University of Southern California
      Los Angeles, CA 90089 * (310) 560-3526
      phoberman@cinema.usc.edu