vichug

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 ?

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 ?


mousestate-polling-too-much

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?

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

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.

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 :

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

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


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... ;)

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?

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

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


mousestate polling too much