vade

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!

callback-for-bpatcher-resize-event

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?

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.

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.

    var loadtask = new Task(resize, this);

        owner = owner.patcher.parentpatcher; 

    // width of our parent bpatcher    

    width = top.rect[2] - top.rect[0];

// refresh our parent patchers on down (?).

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

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.

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.


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.

> The mouse up/patch unlocked thing is a bit too hackish for me, 

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.

> The mouse up/patch unlocked thing is a bit too hackish for me, 
> unless I am 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.


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.

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

Callback for bpatcher resize event?