bug report: mousestate/textbox/numberbox

Oct 30, 2006 at 9:13pm

bug report: mousestate/textbox/numberbox

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;
#N vpatcher 20 74 1096 945;
#P window setfont “Sans Serif” 9.;
#P window linecount 1;
#P newex 171 153 48 196617 loadbang;
#P window setfont “Sans Serif” 12.;
#P window linecount 6;
#P comment 405 303 376 196620 2. now click repeatedly in the text box. just as you’d expect (because now the text box has the focus) the toggle and the button don’t activate , the big number box doesn’t update , but… the number that prints out is the current number in the small number box – which means that the big number box is outputting a different number than it is displaying!!;
#P button 171 351 29 0;
#P window setfont “Sans Serif” 9.;
#P window linecount 1;
#P newex 171 480 32 196617 print;
#P number 171 398 35 9 0 0 0 3 0 0 0 221 221 221 222 222 222 0 0 0;
#P newex 82 360 62 196617 prepend set;
#N counter 10000;
#X flags 0 0;
#P newobj 82 336 77 196617 counter 10000;
#P window setfont “Sans Serif” 24.;
#P user textedit 403 424 638 474 98352 3 24 “magic numbers!”;
#P window setfont “Sans Serif” 9.;
#P newex 171 304 32 196617 sel 1;
#P newex 171 196 63 196617 qmetro 100;
#P toggle 171 176 15 0;
#P toggle 171 242 56 0;
#P newex 171 221 66 196617 mousestate;
#P window setfont “Sans Serif” 36.;
#P number 171 421 197 36 0 0 0 3 0 0 0 221 221 221 222 222 222 0 0 0;
#P window setfont “Sans Serif” 12.;
#P window linecount 4;
#P comment 243 177 305 196620 1. click anywhere in the locked patch. just as you would expect , the toggle and the button are activated , the big number box updates , the current number prints out in the max window.;
#P window setfont “Sans Serif” 24.;
#P window linecount 1;
#P comment 145 112 472 196632 demo of mousestate/textbox/int bug;
#P window setfont “Sans Serif” 12.;
#P comment 171 516 380 196620 tested on MacBook Pro OS X 10.4.8 , MaxMSP 4.5.7 and 4.6.2;
#P connect 7 0 10 0;
#P connect 10 0 11 0;
#P connect 16 0 6 0;
#P connect 6 0 7 0;
#P connect 7 0 4 0;
#P connect 4 0 5 0;
#P connect 5 0 8 0;
#P connect 8 0 14 0;
#P connect 14 0 12 0;
#P connect 11 0 12 0;
#P connect 12 0 3 0;
#P connect 3 0 13 0;
#P pop;

#28440
Oct 31, 2006 at 10:19am

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

#87322
Oct 31, 2006 at 10:34am

>
>> 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

#87323
Oct 31, 2006 at 10:42am

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

#P window setfont “Sans Serif” 9.;
#P window linecount 1;
#P newex 70 261 64 196617 print Button;
#P newex 70 179 61 196617 metro 50 1;
#P button 70 238 15 0;
#P newex 160 89 48 196617 loadbang;
#P window setfont “Sans Serif” 12.;
#P window linecount 6;
#P comment 394 239 376 196620 2. now click repeatedly in the text box. just as you’d expect (because now the text box has the focus) the toggle and the button don’t activate , the big number box doesn’t update , but… the number that prints out is the current number in the small number box – which means that the big number box is outputting a different number than it is displaying!!;
#P button 160 287 29 0;
#P window setfont “Sans Serif” 9.;
#P window linecount 1;
#P newex 160 418 32 196617 print;
#P number 160 334 35 9 0 0 0 3 0 0 0 221 221 221 222 222 222 0 0 0;
#P newex 261 284 62 196617 prepend set;
#N counter 10000;
#X flags 0 0;
#P newobj 261 260 77 196617 counter 10000;
#P window setfont “Sans Serif” 24.;
#P user textedit 392 360 627 410 98352 3 24 “magic numbers!”;
#P window setfont “Sans Serif” 9.;
#P newex 160 240 32 196617 sel 1;
#P newex 160 132 63 196617 qmetro 100;
#P toggle 160 112 15 0;
#P toggle 160 178 56 0;
#P newex 70 211 66 196617 mousestate;
#P window setfont “Sans Serif” 36.;
#P number 160 357 197 36 0 0 0 3 0 0 0 221 221 221 222 222 222 0 0 0;
#P window setfont “Sans Serif” 12.;
#P window linecount 4;
#P comment 232 113 305 196620 1. click anywhere in the locked patch. just as you would expect , the toggle and the button are activated , the big number box updates , the current number prints out in the max window.;
#P window setfont “Sans Serif” 24.;
#P window linecount 1;
#P comment 134 48 472 196632 demo of mousestate/textbox/int bug;
#P window setfont “Sans Serif” 12.;
#P comment 160 452 380 196620 tested on MacBook Pro OS X 10.4.8 , MaxMSP 4.5.7 and 4.6.2;
#P connect 12 0 3 0;
#P connect 3 0 13 0;
#P connect 4 0 17 0;
#P connect 7 0 5 0;
#P connect 7 0 10 0;
#P connect 6 0 7 0;
#P connect 17 0 19 0;
#P connect 18 0 4 0;
#P connect 11 0 12 0;
#P connect 14 0 12 0;
#P connect 8 0 14 0;
#P connect 5 0 8 0;
#P connect 16 0 6 0;
#P connect 10 0 11 0;
#P window clipboard copycount 20;

#87324
Oct 31, 2006 at 11:00am

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;

#87325
Oct 31, 2006 at 5:52pm

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

#87326

You must be logged in to reply to this topic.