By default, patcherargs "fires" (sends out the args and attributes) AFTER the parent patcher's loadbang. It makes more sense to have the patchersargs fire AFTER the parent patcher's loadbang. In order to implement this you can have a loadbang object in your abstract patcher which will bang the patcherargs object. Since loadbang of a sub-patcher fires before it's parent, this would cause the patcherargs to fire before the parent.
See relevant BUG with this workaround, later on in this page<b>
(please list things that you believe to be errors or omissions from the existing ref page)
When an abstract patcher is instantiated via script, typing in a new object, or deleting the object and using ctrl+z, and within that abstract patcher there is a loadbang object connected to patcherargs object, then when the loadbang bangs the patcherargs object, empty args and attributes are sent tout. (only later when the patcherargs object it triggered by Max, then the actuall args and attributes are sent)
This behaviour is inconsistent behaviour, because when the mentioned abstract patcher is instantiated during a normal loading (File->open) then the loadbang causes the actual args and attributes to be sent.
The patcherargs loading order is AFTER the loadbang of the parent, which is not a common wanted scenario. Usually, I want my abstract-patcher object to finish initializing itself before any interaction with it, similar to a "Constructor" in Java, C++ ,... meaning that I want the patcherargs to work BEFORE the loadbang of the parent patcher.
To implement this behaviour, I connect a loadbang object to the patcherargs object. The documentation states, that when the patcherargs receives a bang message it outputs the args and attributes.
BTW: of course if I implement such a solution, I need also to block the second initialisation which happens when the patcherargs object naturally outputs the args and attributes, to avoid double initialisation.