mousestate polling too much
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 ?
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?
Check out the active object.
-ben
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...
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.
hm... it's not exactly what i intended to explain, so here is what i'm trying to do :
thanks for caring anyway !
Ah, yeah, that won't work. One way to do it is with the hover object and a named bpatcher:
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... ;)
Why not just put the active object in the top level patcher, and have an inlet to control polling on the bpatcher?
hi Chris,
that's what i choosed at the moment, but having it inside the bpatcher would have been really nice.