Forums > MaxMSP

Creating a UI: Stand-alone Windows Containing UI Elements

Apr 11 2014 | 3:51 pm

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?

Apr 12 2014 | 10:10 pm

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

Apr 14 2014 | 1:55 pm

Awesome, thanks!

Apr 15 2014 | 12:41 pm

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.

Apr 15 2014 | 1:21 pm


Apr 15 2014 | 2:05 pm

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.

Apr 15 2014 | 2:11 pm

-- Pasted Max Patch, click to expand. --

Apr 15 2014 | 2:13 pm

ah great thanks!

Apr 16 2014 | 12:54 pm

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?

Apr 16 2014 | 3:38 pm

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

Apr 17 2014 | 12:03 am

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.


-- Pasted Max Patch, click to expand. --

  • This reply was modified 2 years by  Rick.
  • This reply was modified 2 years by  Rick.
Apr 17 2014 | 4:06 am

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…

Apr 17 2014 | 5:18 pm

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.

  • This reply was modified 2 years by  codedorf.
  • This reply was modified 2 years by  codedorf.
Apr 17 2014 | 5:32 pm

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!

-- Pasted Max Patch, click to expand. --

Apr 17 2014 | 9:05 pm

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:

-- Pasted Max Patch, click to expand. --

Apr 18 2014 | 11:11 am

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.

Apr 18 2014 | 5:36 pm

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.

Apr 18 2014 | 5:40 pm

Yep yep!

Viewing 18 posts - 1 through 18 (of 18 total)

Forums > MaxMSP