dialog object not saving settings in inspector
In Max 9.0.3, I am changing a few settings for a [dialog] object in Inspector: changing mode to "Extended (Yes/No/Cancel)" and adding label text for the pop-up. Whenever I save these changes and close the patch, they are gone (set back to Default) when I re-open.
Can anyone confirm that this is a bug?
Thanks!
rather enter arguments in object itself.
you can also set all on the fly

Thanks for the tip!
Just curious, though: is it normal behavior for it to disregard changes in inspector?
I would trust that all objects that have inspector and attributes should
store set ones with the patcher.
Depends on the object and attributes, some get saved with the patcher, some other don't unless specified in the objects box.
Maybe I'm mistaken, but it seems the general rule is that UI objects (umenu, jit.cellblock, matrixctrl) have their attributes saved with the patch (as there is no way to edit the text in the object box once the object is created like other objects), and other objects (those represented with the regular object box) don't.
In other words, if your object is a regular object, write your custom attributes in the object box (or dynamically send them alongside other instructions as demonstrated by Source audio). If it's a UI object, you can just change them in the inspector and save the patch.
I would trust that all objects that have inspector and attributes should
store set ones with the patcher.
I disagree. Would mean that all attributes set on the fly get saved with the patch, so it would become quite cumbersome to keep your patch in a "blank" state. Especially thinking about jitter-oriented patchers, where you always change position, color, etc. attributes.
Interesting, thanks!
everything set in the inspector should be saved with the patch.
Definitely not the case, and still disagree! I didn't tried them all, but gl (OB3D) attributes of jit.gl objects, pattrstorage attributes, zlmaxsize
of zl objects... all aren't saved with the patcher if only changed in the attribute.
Only exceptions I found so far are box attributes (which makes complete sense), UI object attributes, coll attributes, and the legacy
attribute of dict (but the quiet
one doesn't get saved). And box attributes, and attribute for UI objects.
I would say it is not consequent, and for that reason irritating,
unless you know what and why.
of course we are all wrong, it is easier.
here is what the doc says docs say:
"Attribute names in the Inspector reveals whether it is saved in a patcher. If the attribute name is printed in italics, its value is not saved with the patcher."
aha.

so, in the given case the inspector correctly shows us that it is not a frozen attribute.
i just wonder why? - it does not make any sense for Display Mode to not have that stored with the patch.
the only thing you can do with those non-frozen attributes in the inspector window is that you drag them onto the object to create an attrui. whos selection then is also not permanent until you loadbang it...
Ahah thanks Roman! The answer was in the doc.