Forums > MaxMSP

mousestate polling too much

January 23, 2011 | 9:14 pm

hia
my question there : isn’t it possible to have a mousestate object to behave as it will only poll events if the windowin which it is embedded is the frontmost window ?? so that your mouse doesn’t accidentally interact with a window invisible under many layers… i would think something that obvious would be some kind of "mode 4" of the object, but i found nothing in the reference. did i miss something ?


January 23, 2011 | 9:34 pm

My first thought was to get the state of your patcher window with thispatcher or pcontrol and use that to turn mousestate polling on and off. A quick look at the thispatcher and pcontrol didn’t turn up an obvious way to determine if the window is frontmost or not. Maybe scripting could help?


January 23, 2011 | 10:05 pm

Check out the active object.

-ben


January 24, 2011 | 10:25 am

Hi Ben,
i checked it and at first glance i thought it was it, but then i realized that it won’t work inside a patcher which is inside a bpatcher. It behaves strangely maybe, i thought "active" inside a bpacher would behave as if it was a part of the parent patcher, but apparently not, and it seems that a patch inside a bpatcher will never report as active ?.. maybe there are other workaround just with the bpatcher object, like a "dont click through" attribute ?
and Holland i checked thispatcher scripting, it won’t be enough, mb js will go further but i don’t know a thing about it…


January 24, 2011 | 3:59 pm

It is working here as expected, but maybe I am missing something about your setup. Maybe post a very simple example that is set up with the patcher hierarchy that you are using.

– Pasted Max Patch, click to expand. –

January 24, 2011 | 7:49 pm

hm… it’s not exactly what i intended to explain, so here is what i’m trying to do :

– Pasted Max Patch, click to expand. –

thanks for caring anyway !


January 24, 2011 | 7:58 pm

Ah, yeah, that won’t work. One way to do it is with the hover object and a named bpatcher:

– Pasted Max Patch, click to expand. –

January 24, 2011 | 8:37 pm

i didn’t know this hover object
it’s my problem nearly solved – i can use this solution but ideally, the whole thing should be inside the bpatcher. I’m beginning to wonder if it’s doable at all, but it would be cool cause i often use that abstraction i want inside a bpatcher, so if i don’t have additive programming to do each time it’s all the best…
Anyway i can live with that solution :) or i can replace the "hover route mybpatcher etc…" by just an "active", wich is enough because i just need the mousestate not to be polling when the parent windows is not the active one.
Again thanks for the help ! wall after wall i progress… ;)


January 24, 2011 | 10:02 pm

Why not just put the active object in the top level patcher, and have an inlet to control polling on the bpatcher?


January 25, 2011 | 11:10 am

hi Chris,
that’s what i choosed at the moment, but having it inside the bpatcher would have been really nice.


Viewing 10 posts - 1 through 10 (of 10 total)