Forums > MaxMSP

Dialog popups when in fullscreen mode

September 10, 2008 | 6:21 am

I’ve made a max patch which is designed to run fullscreen as a kiosk app. I’m achieving the fullscreen by sending a "thispatcher" object a "fullscreen 1" message. One of the functions of the patch is to collect text input from a user with the "dialog" object. Everything works fine when the patch is not in fullscreen mode, but when it is fullscreen the dialog box pops up underneath the main window so that it can’t be seen. Does anyone know how to get around this problem?

I’ve attached a really basic example showing the problem I’ve encountered. If anyone can help with this I’d be really grateful!

Phil


September 10, 2008 | 6:48 am

I can confirm your problem (Max504, OSX54).
Interestingly, the same thing happen if you use ; max hidemenu. The
dialog window is not hidden behind the main window (I checked), but
must be somewhere as you have to hit enter or esc (i.e. you have to
leave the dialog) to be able to turn off fullscreen or having ;max
showmenubar working.

On 10 sept. 08, at 08:21, Phil McPhee wrote:

> I’ve made a max patch which is designed to run fullscreen as a kiosk
> app. I’m achieving the fullscreen by sending a "thispatcher" object
> a "fullscreen 1" message. One of the functions of the patch is to
> collect text input from a user with the "dialog" object. Everything
> works fine when the patch is not in fullscreen mode, but when it is
> fullscreen the dialog box pops up underneath the main window so that
> it can’t be seen. Does anyone know how to get around this problem?

____________________________
Patrick Delges

Centre de Recherches et de Formation Musicales de Wallonie asbl

http://www.crfmw.be/max


September 10, 2008 | 5:35 pm

In its effort to enforce its superior level of user interface quality, the Mac OS does not permit certain types of windows to appear in applications without menu bars. Or, more accurately, it punishes the application by putting windows that are supposed to be in front behind other windows. A workaround would be to bring a patcher window to the front or use a third-party object. Or just show the menu bar temporarily. We’ll try to find a similar way of using non-dialog-window dialogs someday.

David Z.


September 11, 2008 | 4:40 am

Thanks for looking into my problem guys… looks like David’s suggestion of opening a new patcher window might be the way forward (unless anyone can recommend a particularly good third-party dialog object?).

Phil


September 11, 2008 | 7:26 am

Phil,

I had the following patch laying around from dealing with this before, maybe it will give you some ideas. Using a patcher is not quite as quick as [dialog] but provides lots of extra flexibility/customization. You will want to save the following patch and reopen.

– Pasted Max Patch, click to expand. –

September 21, 2008 | 9:23 am

Ben Bracken schrieb:
> I had the following patch laying around from dealing with this
> before, maybe it will give you some ideas. Using a patcher is not
> quite as quick as [dialog] but provides lots of extra
> flexibility/customization. You will want to save the following patch
> and reopen.

Liked the patch, made some modifications, so that it will close the
window if you hit return, and doesn’t need so many external elements…
(It also prevents sending the typed text if you hit cancel, or defocus
the textedit…)

– Pasted Max Patch, click to expand. –


Stefan Tiedje————x——-
–_____———–|————–
–(_|_ —-|—–|—–()——-
– _|_)—-|—–()————–
———-()——–www.ccmix.com


February 13, 2009 | 4:04 am

FYI I just found this patch really really helpful. thanks.


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