Developing UI Component Classes | post-setup initialisation method ?

Regarding classes derived from matlab.ui.componentcontainer.ComponentContainer:

¿Does there exist (or is there a way of defining) a method which executes:

• once only;
• after the setup method;
• before the update method?

Motivation is (irreversible) object initialisation conditional on one or more property values passed to the constructor.

To this end, the setup method is unsuitable since

"Any property values passed as name-value pair arguments to the UI component's constructor method are assigned after the setup method executes."

The update method is by definition, not a one-shot method.

Answer 1

[Amos]

I'll clarify (and answer) my question with the benefit of hindsight:

I was hoping for a standard method to inject code into the component-constructor, post- (and maybe another, pre-) invocation of the superclass constructor**, analogous to postSetupFcn for setup.

{** noting the superclass constructor invokes the (overridden) setup method}

Seems this doesn't (yet) exist.

While often such a requirement might be avoided by alternative (better?) design, a direct solution is to explicitly define the component constructor.

[Greg]

A strong caution against explicitly defining constructors for component containers. It is not the intended design pattern (I have had conversations with the developers), and it causes (additional) unpleasant behavior starting in R2022a. I forgot the exact details, but none of my pre-existing component containers work in R2022a. It is mentioned as a compatibility in release notes: "ComponentContainer class assigns a parent before executing the setup method"

My own work has moved away from component building, so I have not had time to investigate this completely, or find a suitable way forward. Hopefully, I can do so soon, as I would like to upgrade to R2022b - it likely releases next week or so.

[Amos]

Thanks again, Greg

I'm not surprised. To date, however, explicit definition of the constructor has proved the path of least grief - at least for my own (mis)use-cases.

My constructor boilerplate necessarily includes (as did my earlier use of postSetupFcn) a guard-clause testing for a figure-ancestor.

Fwiw, finding R2023a more robust than R2022a,b. Nevertheless, appdesigner seems quite cable of crashing itself and MATLAB when loading a problematic mlapp file, particularly as a sub-component (even if lintless and running in isolation). Not the most reassuring feature when developing complex apps with mulitple layers of custom components.

Answer 2

[Greg]

Your part about "before the update method" is a moving target. The update method is supposed to execute during a graphics flush (i.e., drawnow or pause calls). So depending on the code, your update method might occur more often than another.

In my componentcontainers, I've found the update method completely useless (and even detrimental). I leave it blank, and build my own method named draw that I can call if and when I want it to execute. A trick I use to accomplish the "do stuff before update" is a "skipUpdate" property. Define it as true by default, then the bottom of the constructor sets it to false. Inside the update method, the very first thing is if obj.skipUpdate;return;end.

[Amos]

Belated thanks, Greg.

Apologies - in retrospect, my reference to the update method was a red herring.

I must say, I've found myself also avoiding update wherever possible.

Cheers