Forums > MaxMSP

Creating a UI: Stand-alone Windows Containing UI Elements

April 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?
Thanks


April 12, 2014 | 10:10 pm

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


April 14, 2014 | 1:55 pm

Awesome, thanks!


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


April 15, 2014 | 1:21 pm

[active]


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


April 15, 2014 | 2:11 pm
– Pasted Max Patch, click to expand. –

April 15, 2014 | 2:13 pm

ah great thanks!


April 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?


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


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

Example

– Pasted Max Patch, click to expand. –
  • This reply was modified 5 months by  Rick.
  • This reply was modified 5 months by  Rick.

April 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…


April 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 5 months by  codedorf.
  • This reply was modified 5 months by  codedorf.

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

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

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


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


April 18, 2014 | 5:40 pm

Yep yep!


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