Thread Subject:

UITable DataChangedCallback-update within callback

Dear group,

for a project I'm using old uitable in order to get access to the java handle easily. Since I want to perform an "valid/invalid" input check, I define a DataChangeCallback performing this check. If the new entry is invalid, I restore the old one.

Since restoring the old value requires turning of the Callback (at least the way I'm trying for the moment), I first turn of the callback, change data and restore the old callback definition. Otherwise an infinite loop is entered.

As could be seen in the example below, this works within the callback definition itself (see last line), but when I change the table a second time, it could be seen that the callback is undefined (seen by jhandle.DataChangedCallback executed in the command window).

Could anyone comment on this behaviour and point out a solution to this problem. Are there another, easy way I just overlooked to resolve this validity-check (not using class definitions of the jtable). Any help is welcome.

Thanks in advance,

Alexander


function TestCallback

figure(1)

% use old style uitable to get the java handle
[jhandle,mhandle] = uitable('v0',1,'data','asd');

% send jhandle to base workspace to check callback manually afterwards
assignin('base','jhandle',jhandle)

% set callback
jhandle.DataChangedCallback = @ChangeCallback;


function ChangeCallback(source, event)

% save old callback
old_callback = source.DataChangedCallback

% set empty callback to avoid infinite loop
source.DataChangedCallback = '';

% change something, triggering the DataChangedCallback
source.setData(repmat(cell(source.getData),2,1))
 
% restore the old callback
source.DataChangedCallback = old_callback;

% check whether the callback is properly set (within the function)
source.DataChangedCallback

"Alexander Mering" wrote in message <jekbvl$dab$1@newscl01ah.mathworks.com>...
> Dear group,
>
> for a project I'm using old uitable in order to get access to the java handle easily. Since I want to perform an "valid/invalid" input check, I define a DataChangeCallback performing this check. If the new entry is invalid, I restore the old one.
>
> Since restoring the old value requires turning of the Callback (at least the way I'm trying for the moment), I first turn of the callback, change data and restore the old callback definition. Otherwise an infinite loop is entered.
>
> As could be seen in the example below, this works within the callback definition itself (see last line), but when I change the table a second time, it could be seen that the callback is undefined (seen by jhandle.DataChangedCallback executed in the command window).
>
> Could anyone comment on this behaviour and point out a solution to this problem. Are there another, easy way I just overlooked to resolve this validity-check (not using class definitions of the jtable). Any help is welcome.
>
> Thanks in advance,
>
> Alexander
>
>
> function TestCallback
>
> figure(1)
>
> % use old style uitable to get the java handle
> [jhandle,mhandle] = uitable('v0',1,'data','asd');
>
> % send jhandle to base workspace to check callback manually afterwards
> assignin('base','jhandle',jhandle)
>
> % set callback
> jhandle.DataChangedCallback = @ChangeCallback;
>
>
> function ChangeCallback(source, event)
>
> % save old callback
> old_callback = source.DataChangedCallback
>
> % set empty callback to avoid infinite loop
> source.DataChangedCallback = '';
>
> % change something, triggering the DataChangedCallback
> source.setData(repmat(cell(source.getData),2,1))
>
> % restore the old callback
> source.DataChangedCallback = old_callback;
>
> % check whether the callback is properly set (within the function)
> source.DataChangedCallback

Turning off a callback within that same callback is generally ignored although no error is generated. Instead, use a programmatic bail-out mechanism. For example: http://UndocumentedMatlab.com/blog/controlling-callback-re-entrancy/

Yair Altman
http://UndocumentedMatlab.com

"Yair Altman" wrote in message <jekurb$khf$1@newscl01ah.mathworks.com>...

> Turning off a callback within that same callback is generally ignored although no error is generated. Instead, use a programmatic bail-out mechanism. For example: http://UndocumentedMatlab.com/blog/controlling-callback-re-entrancy/

Hello Yair,

thanks (again) for the right hint.

I finally decided not to use the isMultipleCall but attach some Userdata to the underlying figure. This, basically following the same route, resolves my issue.

Alexander