I only used a local reference to point at the toolbar object.
So you need to do this all from within the same extension submodule.
Each button will need it’s own image file, and it’s own UI::Command object that fires it’s own command method.
You kinda did this, but in a separate top level module (The only toplevel module you should use is your unique company or author namespace module. All of your extensions must be defined inside this namespace module.)
There is another topic on redrawing DC instances.
… but I’ll paste the code into a new example (below.)
DC attributes that begin with "_" have a special meaning. The end user never sees these attributes as they are really variables used by a DC property and the DC code. (I use the word “property” to mean one of the options that end users can see and change.)
There are “secret” DC attributes you are not adding to the component definition.
Also, the instance must get a small DC attribute dictionary.
More on this in the next post with an example …
Rather than use a zillion literal “dynamic_attributes” strings, set a reference to the name once, and reuse this …
# near top of submodule ...
DCDICT ||= "dynamic_attributes"
# Then later in the code ...
obj.set_attribute(DCDICT, "c_mn", "")
Many DC attributes are kept in the definition’s “dynamic_attributes” dictionary, not the instance’s “dynamic_attributes” dictionary. There are only specific situations where the attributes from the instance’s “dynamic_attributes” dictionary are used.
Also nested dynamic groups always have the DC attributes attached to the group instance.
So the general rule is to first check the instance for an attribute, and if it does not exist (returns nil) then check the definition for the DC attribute.
The DC definition will have all the default values for all the property attributes. The instance will only have an property attribute if it differs from the default value in the definition.