Callback for bpatcher resize event?

Dec 5, 2007 at 8:05am

Callback for bpatcher resize event?

Hello

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!

WOOO!

#34895
Dec 6, 2007 at 4:28am

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?

#118335
Dec 6, 2007 at 4:42am

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.

#118336
Dec 6, 2007 at 5:24am

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 = prev.box;

// 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();

}

#118337
Dec 6, 2007 at 5:24am

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.

#118338
Dec 6, 2007 at 5:53am

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.

#118339
Dec 6, 2007 at 6:30am

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

#118340
Dec 6, 2007 at 6:38am

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.

#118341
Dec 6, 2007 at 6:39am

erm sorry, which runs once, only once, on load. That task never runs again. (to be clear).

#118342

You must be logged in to reply to this topic.