codedorf

I am wondering if it is possible to give the user of my MAX patch the ability to open new windows with new UI elements inside of them. For instance, I would have three toggle boxes in presentation mode labeled "control panel", "data", and "metrics" and if you toggled a box, then a new window popped up with UI elements in them (by UI elements I mean objects from my max patch in presentation mode). So far, the closest I have come is to be able to hide and show groups of objects in presentation mode using toggle boxes, but it would be great if these groups of objects could appear in separate windows.

Hi All,
I am wondering if it is possible to give the user of my MAX patch the ability to open new windows with new UI elements inside of them. For instance, I would have three toggle boxes in presentation mode labeled "control panel", "data", and "metrics" and if you toggled a box, then a new window popped up with UI elements in them (by UI elements I mean objects from my max patch in presentation mode). So far, the closest I have come is to be able to hide and show groups of objects in presentation mode using toggle boxes, but it would be great if these groups of objects could appear in separate windows.
Is this possible?
Thanks


creating-a-ui-stand-alone-windows-containing-ui-elements

Yes. Look at "pcontrol" and the "open" and "close" messages.

Is there a way to query the state of a encapsulated patch to see if it's edit window is open or not?

That way I could save the state of the window (whether it was open or closed) when quitting MAX, and recall that state upon opening the main MAX patch again later.

Is there a way to query the state of a encapsulated patch to see if it's edit window is open or not?
That way I could save the state of the window (whether it was open or closed) when quitting MAX, and recall that state upon opening the main MAX patch again later.


is [active] an attribute on an object? Because if so, it isn't showing up when I option+click the left inlet of either the subpatcher or the pcontrol object.

Ahhh but [active] doesnt actually work for what I need to do, because [active] only tells you whether the window is "the front most window." This means the actual window of interest can be open, but if it is not the window that the user is currently interacting with, then the [active] object will output a 0. I need a way to query if the window is open at all, not just if it is the current "active" window. Is this possible?

I might be wrong here, but I don't think there is any direct way of doing this. You may need to devise your own window opening and closing methods, using pcontrol-- and disable the window close box (using thispatcher) so the user can only close the window with a close-button or whatever you provide in your patch-- then you can keep track of whether the window is closed or open (ie keep it in a value object(s))

FWIW You don't have to keep track of the open or closed state of your sub patchers if you save your main patcher before closing. A loadmess dirty message to the thispatcher of your main patch would prompt a reminder to save the current state when exiting.

Edit. But since your creating a stand alone... a window is at least active the first time is is opened. If it is later closed a closebang message would signal a state change.

yes I forgot about closebang-- but there have been occasions where I've had to resort to other strategies to keep track of whether or not a window is open or closed (or active or inactive). I think if it's a floating window the 'rules' change somehow... maybe it's active state isn't updated or something. probably should keep my vagueness to myself...

The problem is that closing the "main" window causes the [closebang] in the subpatcher to activate. When closing a patcher, first the main window is closed, and then subpatcher windows are closed. So you have a situation where your subpatcher window is open, and you queried an "active," but when you close the main patcher, the subpatcher [closebang] fires anyway, and the last thing you do before the entire patch closes is query a bang from the closebang :/ Working on a solution involving [coll] and having a [closebang] from the main patch disable the [closebang] in the sub patch.

The problem is that closing the "main" window causes the [closebang] in the subpatcher to activate. When closing a patcher, first the main window is closed, and then subpatcher windows are closed.  So you have a situation where your subpatcher window is open, and you queried an "active," but when you close the main patcher, the subpatcher [closebang] fires anyway, and the last thing you do before the entire patch closes is query a bang from the closebang :/ Working on a solution involving [coll] and having a [closebang] from the main patch disable the [closebang] in the sub patch.


I was able to get a patch working! There's definitely other ways of doing it, and if anyone has any ideas on a more elegant implementation, I'm down to hear them.

I was able to get a patch working! There's definitely other ways of doing it, and if anyone has any ideas on a more elegant implementation, I'm down to hear them.
Thanks for all the help guys!


I'm not sure exactly what you want to do, but you can use the value object to store arbitrary messages instead of using coll; also use send and receive to update:

Hmmm, I tried the patch you linked but when I had the subpatch (window 1) opened, and quit MAX, and then relaunched MAX, the subpatch (window 1) did not re-open automatically.

OK, yes, you want to save window configurations between relaunches; using coll is the way to go. the value object doesn't write it's state to file.

Creating a UI: Stand-alone Windows Containing UI Elements