mousestate polling too much

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

    • Jan 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?
    • Jan 23 2011 | 10:05 pm
      Check out the active object.
    • Jan 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...
    • Jan 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.
    • Jan 24 2011 | 7:49 pm
      hm... it's not exactly what i intended to explain, so here is what i'm trying to do :
      thanks for caring anyway !
    • Jan 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:
    • Jan 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... ;)
    • Jan 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?
    • Jan 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.