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
for gui shit in high priority situations
or delay groups of loadbangs when a hughe app has to be initialised on startup.
"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…
----------begin_max5_patcher---------- 593.3ocyVssaiBCE7YxWAxOyF4K3a6Gx9RUzJZvMwUDSD3Hkcq59su9Bj.61 jpPaZhTjAli8wimyvI7xrDvi06Usfzum9PZRxKyRRBPdfjtmS.aJ1urpnMLM vFUaawJEHKFyp1aC3aKrKWqMq9415VsUWaRwPXJAB6moY2l5c1JkMjGTG5gk 0nVZi7fPEygYtkK8WPLV3hCKcQ+hZTsJisvuMCSltLPk5Ge9a39sMtm1esUE yN.bHMOUarlhMg.fenZJKLEfAwZ0+NDCgbL3+24ATNOGEoL4TT1c50l9CO1i 85rY9grOKc2y1TpSyQSWyQ7Hyo7on4jaglin4mhxWOMeHiN32Qd69jU9b1Gv sKuIJOm8061GxnfiO263oSW2QxOfiWbSzcr7K2wGjZWybeS8oJ0RreTHmhPy uIBcrc9av3qm+9XyjQMxGQzJsQsrdmIrD7kWMB9FV9fi3kVNX2hxAEdrZPPe lUimzUVUyplhsq+ya6t4mVOwz3+8Si1jbZfqxKSPQmTPqzsVPliiU0Eu2M8y U6sFKNunh3AhhE3XS7XyDL+T5pnGLJVALRGVqxFQ6TD242kqrTX3m.xmKY4b AwANmQyEHer4boyfGtCdlAz3j4DVojyobeXICgf9nywRBTvdubAGmKBRj6xA Uf8wEBDIOjBGWwHx4SV5hA9rfhA7uV9OeJcvt3wGa9Zq20rru.28kSoG08RU qUaNXWd3fEYvbVqKKUgv8u7rQWts1U46nvHBlcwLBe2wH1cGi32cLRb2wH4U lQtGdc1eAjKlygE -----------end_max5_patcher-----------
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.