Topic: Question about ui element synchronization

Question about ui element synchronization

Apr 20 2010 | 7:04 pm

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

Roman Thilenius

Apr 20 2010 | 7:10 pm

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.

seejayjames

Apr 21 2010 | 3:42 am

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

stefantiedje

Apr 21 2010 | 11:04 am

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…

-- Pasted Max Patch, click to expand. -- Copy all of the following text. Then, in Max, select New From Clipboard. ----------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-----------

Ed Majcher

Apr 21 2010 | 4:41 pm

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.