"window flags notitle" breaks pwindow in a bpatcher
Similar to this issue.
If I send "window flags notitle, window exec" to [thispatcher]
all the pwindows in my bpatcher break.
this is making it tricky for me to build a custom fullscreen mode, and manage some of the other display settings that I want. Is this expected behavior? Is there something I should be doing to address it?
Thanks!
Hi, this is becoming a bit of a problem for me. I'm using bpatchers extensively in my app. Basically my top level patch is an app selector that loads different bpatchers based on user selection.
Inside the bpatchers I use pwindows to display various small visualizations.
At the moment I don't have any solution to allow the user to manage the display settings and allow a fullscreen mode.
Does anybody have any ideas why this may be happening?
it looks like this isn't possible currently(you're also using jit.pwindow instead of the newer jit.pworld which is what you would use for GL stuff, but when i switch your jit.pwindow to jit.pworld and then re-embed the bpatcher and try all over again(i can remove the jit.gl.render altogether in such a case and attach bangs straight to the jit.gl.gridshape and it begins drawing straight to the similarly named [jit.pworld mything]), the problem gets worse everytime i try the "window flags notitle, window exec" message and then switch it back it stays broken... which means the problem is worse when you use jit.pworld).
since the problem gets worse when i use the newer GL drawing context meant for this situation, i'm thinking that under-the-hood, the 'window flags notitle, window exec' messaging system to [thispatcher] needs some additional messaging to specify certain windows by name only so that it doesn't affect all drawing contexts(?)
others can chime in if i'm wrong: but currently, i don't think this is possible, i'd suggest rethinking your preview/monitoring solution around maybe building something in a separate window for preview/monitoring only(like all the thumbnail sized previews get drawn in tile-formation to one single jit.world window, and then your main view is in another separate jit.world window).
hope it at least helps get some deeper understanding into the issue.
changing the style of the window moves the window... then the bpatchers are forgotten when a redrawing should happen? just guessing around.
i would try to redraw everything via message-to-max, maybe that fixes it already?
Thanks for the suggestions here. Unfortunately, Roman, ";max refresh" didn't do anything. Are there any other messages I could try?
R∆J∆, thanks for the tips regarding jit.pworld. That will simplify my patches a bit moving forward. Your suggestion makes sense for preview/monitoring. But what I'm trying to do here is write a desktop app that behaves like other 3d applications users are familiar with (like games). Where the user can choose to run the app in a window or in fullscreen mode.
It looks like changing the @name of the pworld/pwindow and then changing it back get things back online on windows at least. This didn't work when I tested in on my mac. So there may be workarounds there. On Mac I have to delete the pwindow and recreate it. Which I could do with scripting... although that is kind of brutal. But if I can reduce the number of pwindows i'm using it might not be too ridiculous.
So there may be workarounds, but they get pretty ugly. It would be great(!) if this could work normally.
After one of the MacOS upgrades, I remember fullscreen mode being problematic and while Max wasn't updated/fixed for that OS version, the recommended solution was to query the size of the monitor and change the size and position of the window to match the "fullscreen". Fullscreen without fullscreen mode.
That might be worth trying in your particular case as an interim solution?
In addition you need to hide menubar if it is
main screen
that is what he is already doing, the window mode seems to break things.
one could try to leave the title bar of the window ON and move the window to -4 -21 or whatever it is, but those numbers will change with every OS then and that is not funny.
hi Joe, thanks for following up with this. We do have this edge case ticketed and reproduced, but unfortunately it has proved difficult to find the culprit. Until we're able to, I think your best bet is to workaround this issue using patcher scripting, i.e. destroying and recreating the pwindow objects whenever the parent window state changes.
I've modified your patch with a basic demonstration of the technique I'm suggesting. Please let me know if anything is unclear.
[edit - you can even use the same pwindow scripting name as the context name, which might make managing this technique easier]
Thanks Rob!
I'm glad to know you've got this reproduced and documented. That will help me sleep at night with the workaround.
The script will also have to capture the patching_rect, presentation_rect, and turn on presentation mode. Gathering those rects is the most painful piece of this. A beautiful thing about Max is that you don't ordinarily have to manage that stuff yourself. But as long as the number of pwindows doesn't get astronomical, I can manually populate a [coll] to store that info. Not fun. But if the alternative is giving up, I'll take it.
The scripting gets tricky because objects only remember their presentation_rect when presentation mode = 1. And of course when you create them they default to presentation mode = 0. So the order of operations in the script is important. Delete. Then create. Then turn on presentation mode. Then set presentation rect.
Here's my solution. If anybody has any suggestions to optimize this I am always curious to improve my Max hygiene in these kinds of patches.