Using dataqueues to log text to an app (appdesigner)

I am encountering an issue with a logging schema and an app I am developing in app designer. The app is designed to provide logged feedback to a text area on the UI, such that a User can determine how a computation is going. This is implemented using a Logger/Appender scheme. I have an Appender class that is instantiated in the app and then has a 'display function' property which holds an anonymous function to log to. Such that in the app the appender is instantiated and configured via

app.appender = Utility.UIFigureAppender;
app.appender.DisplayFunction = @(msg) app.addToDisplay([],msg);

the add to display function formats the message, handles input checking and then sets

app.loggingInformation.Value{end+1} = messageString

The logger itself utilises dataqueues such that a node can send logged data to the head. Further, each appender is distributed across each node using dataqueue as shown below. I think this is where my issue resides. Code snippets follow:

function determineDataQueueEvent(evt)
switch evt.source
case 'log'
Logger.log(evt.data)
case 'addAppender'
Log.Logger.distributeAppender(evt.data)

[...]
end
end

function generateLogEvent(level,msgIdent,msgString,varargin)
data = Log.LoggingEvent(level,msgIdent,msgString,varargin)
evt.data = data;
evt.source = 'log' %there are other events that can be sent, e.g. addition/deletion of appender
Log.Logger.queue(evt);
end

function queue(evt)
obj = Log.Logger.getInstance; %singleton paradigm
send(obj.loggingQueue,evt)
end

the data queue in the logger class is called whenever a log message is made or an appender is added, the determineDataQueueEvent function determines how the head node handles this. That is to say my dataqueue is set up as

afterEach(obj.loggingQueue,@Logger.determineDataQueueEvent)

In the case of the Utility.UIFigureAppender this reads as

[...]
this.DisplayFunction(message);
[...]

From debugging, I believe my issue is that in using the dataqueue and that in distributing the Utility.UIFigureAppender the handle to the app in the anonymous function now points to a new app. I have confirmed that the 'addToDisplay' call is not carried out in the app which spawns the log message based on some assignin('base',...) compares.

Is there anyway to keep the same app handle in the anonymous function when the appender is distributed across the nodes?

Other thoughts/comments welcomed. Sadly I cannot attach the full files as the code resides on an airgapped pc (and so code may contain typos too!)

Thanks for any help

[Guillaume]

It's difficult to understand your problem as you appear to be using a fairly complex (and well designed) framework for which we don't have the details.

However,

the handle to the app in the anonymous function now points to a new app

Matlab apps (derived from matlab.apps.AppBase) are handle classes. So are Matlab uifigures. Therefore matlab will not instantiate a new object when you merely pass handles from function to function. Anonymous functions don't change that.

Note: to check that two handles refer to the same object use == (not isequal). To check that your object is indeed a handle class, use superclasses and check that handle is in the list.

[A Mackie]

Thanks for your comment, I was afraid that it would be hard to provide feedback without the full context, but am not sure on how to explain any better?

Yes, I am aware the apps are handle classes. I have checked through the == operator that the app launched from the command line and the app utilised when the anonymous function referenced are not the same (managed through an

assignin('base','app',app)

call - I would assume, again, since the app is a handle this shouldn't create a copy?)

My assumption is that by utilising

parallel.pool.DataQueue

and the associated

afterEach

there is a copy being called by matlab, which is by value and not by reference - but I am not sure if this is the case and if it is, how to work round this/modify to sit within this constraint.

If there are more details that make this easier to understand, please let me know.

[Guillaume]

Then, I would assume that the problem comes from the way the parallel toolbox manages handle classes. Unfortunately, it's not something I can help with as I don't that toolbox.

I've changed the product associated with your question from matlab to parallel toolbox to give it more visibility to the right people.