Question about ui element synchronization
Does the output of a ui element (like umenu) follow the same message flow as every other standard max object or does the message flow effectively end when once it hits a ui element? I am seeing very odd results upon load of a patch where the output of umenu is part of an expected flow that should drive some objects that follow it but it never appears to complete on time. I have some more testing to try out tonight by adding some prints statments to see if the order of execution is occurring the way I expect it.
I suspect the output of a ui element does not guarantee message flow ordering upon loading of a patch and I need to separate out usage of my code from the ui (which is the better programming model to begin with.
I know this question might be vague without a patch example, but I thought I would throw it out in case anyone knew of something that wasn’t documented.
Secondly, is there a process to submit updates to the documentation, for example, the undocumented feature of send and receive supporting patch isolation via prefixing the names with —.
it even worse, ui elements can slow down the message if a message goes thru them,
so it can be cool to use
t f f
defer |
for gui shit in high priority situations
or delay groups of loadbangs when a hughe app has to be initialised on startup.
undocumented stuff?
"position $1 $2" to a message box…or bang… or lots of other things… but not to a standard object.
found that one when I was sending GL commands to a gridshape, and hooked it up to a message box accidentally… it zipped to the upper-left corner of my patch. it was bizarre. anywhere in the docs?
It seems similar to "patching_rect $1 $2 $3 $4" or "script move
It seems not documented, at least not in a way to find it simply (which is practically the same…)
There is more to explore, it works with a lot of GUI objects…
There was a thread which covered it as an answer from Emmanuel. Till this it was not known to me, and stills seems hidden/buried somewhere…
All my self adjusting bpatchers could have been so much easier…
I spent the time unravelling my bpatchers, removing the ui elements that were part of the message flow and moved them all to the top level of my patch and I update them as a side effect of the results of other objects and everything works perfect now.
As painful as this was to diagnose, separating out the ui from the logic is a better design anyway so I should have known better in the first place.
….separating out the ui from the logic is a better design anyway so I should have known better in the first place.
Look on the bright side – there are some people who’ve never figured this out. :-)
FWIW, it’s documented as part of the common attributes of any object.