Callback for bpatcher resize event?

    Dec 05 2007 | 8:05 am
    Ive got some nifty GUI code that checks the parent bpatcher size on a function call and reflows my gui to my wishes (YAY! Confetti!!@#)
    Now, id love to know if there is some callback my javascript can hook into to see if its parent patcher is being resized or moved, so I can fire off my resize event (for dynamic resizing)
    Im not using JSUI, im using standard max objects within a bpatcher.
    Thanks, *super* curious. I should have moved this crufty olde code to JS a while ago - makes things HANDY!

    • Dec 06 2007 | 4:28 am
      Don't think so. Use the [mousestate] object to send every mouse-up to your js, (efficiently) check the patcher size, rearrange if it's changed?
    • Dec 06 2007 | 4:42 am
      Hm, I really dont want to have to poll, that would be very bad with many gui objects. Oh well, ill see what I can manage.
    • Dec 06 2007 | 5:24 am
      So, I have a resize function which reflows my gui - I was able to use a task within the loadbang function with a delay to get my initial resize working. No idea how on earth to do others, but I think its ok, since resizing will be an editing task, and users can just click the damn resize message box if they need to reflow.
      Once they set it, this function will do it for them when the patch is saved.
      function loadbang() { var loadtask = new Task(resize, this); loadtask.schedule(100); }
      function resize() { prev = 0; owner = this.patcher; while (owner) { prev = owner; owner = owner.patcher.parentpatcher; } if (prev) top =;
      // width of our parent bpatcher width = top.rect[2] - top.rect[0];
      do your reflow here if you want
      // refresh our parent patchers on down (?). prev.parentpatcher.refresh(); prev.refresh(); this.patcher.refresh();
    • Dec 06 2007 | 5:24 am
      It doesn't require polling, unless you want a "live" resize on drag.
      You can make the window-size check quite efficient, and you only do that on mouseup anyway - which really won't be very frequent, compared to polling every 100ms or so.
      So you still don't run any of your GUI-resize code unless the patcher size has changed.
    • Dec 06 2007 | 5:53 am
      hrm? task.schedule() only runs once according to the docs, and yeah, the whole point was to get a live resize so when people are editing the patches the guis update :)
      The mouse up/patch unlocked thing is a bit too hackish for me, unless I am misunderstanding.
    • Dec 06 2007 | 6:30 am
      > The mouse up/patch unlocked thing is a bit too hackish for me, > unless I am misunderstanding.
      Maybe I'm misunderstanding?
      The user can't resize anything without clicking/dragging on it with the mouse, right? When the mouse is released, the resize (if there was one) is done. You feed the mouseup from mousestate to your js, which checks the patcher to see if the width/height is different. If it is, you rearrange your GUI. If it isn't, you do nothing. No polling via js task or otherwise is required, it's a mouse-driven event.
    • Dec 06 2007 | 6:38 am
      Well, mouse state polls, maybe not in JS, but in max code.
      btw, my code is not polling at all, that task has a schedule, while runs once, delayed by 100ms because there is some delay required for the subpatch within my bpatcher to realize it is in a parent and traverse the hierarchy up. Otherwise with no delay it throws an error.
      Logic wise I think we are in agreement, however, this isnt for a window, but for a bpatcher, where I plan on have MANY MANY of them, so I suppose I could be polling in one location, send the event globally, to fire it off, I may give it a shot, but my above solution works for what I need to do.
      These ui objects are the heart of my performance environment, so I want to keep them as lean as possible.
      Thanks, I may give something like that a shot at some point.
    • Dec 06 2007 | 6:39 am
      erm sorry, which runs once, only once, on load. That task never runs again. (to be clear).