accessing timer UserData fields

t=timer;
t.UserData = struct('field1', 'a', 'field2, 'b');

t.UserData.field1
% returns an error:
%inconsistently placed '.' in subscript expression

get(t.UserData, 'field1')
%returns an error:
%Conversion from double to struct not possible

get(get(t, 'UserData'), 'field1')
% returns same error

u = t.UserData;
u.field1 %works fine

Thus I have a workaround but it's kind of clunky: I set a variable to u=t.UserData at the beginning of my timer callback function and then set t.UserData=u at the end of my timercallback function

Why can't these fields be accessed directly?

Answer 1

[Walter Roberson]

Interesting, I had never seen that message before.

The work-around is

getfield(t.UserData, 'field1')

[Joris Lambrecht]

Thanks! Seems there is still a bug in Matlab given that the UserData does not show as expected using the property inspector

[Joris Lambrecht]

Unfortunately, the counter to this does not seem to work. If I want to set the value of the field:

setfield(t.UserData, 'field1', 'c')

returns field: 'c' as expected, but a follow up call to

   getfield(t.UserData, 'field1')

returns 'a'

[Walter Roberson]

t.UserData = setfield(t.UserData, 'field1', 'c')

setfield does not assign to a variable: setfield returns the modified value.

As to why it happens:

MATLAB objects can have properties that are represented as fields in a struct that is marked as being of the appropriate class. If any given property happens to be a struct and the property is directly represented as a struct field, then it can be sub-referenced in the way that would seem natural.

But MATLAB objects can also have properties that are calculated rather than being directly represented, "Dependent" properties. Nearly everything about timers are implemented as Dependent properties, with the code that handles the implementation accessing a java object that is directly stored in a struct. Dependent properties cannot be sub-referenced in the way that would seem natural. When I look at the implementation of timer.m it appears to me that the Dependent properties might be created as dynamic properties; I do not know the backing implementation for those.