My approach is instead of calling

varargout = func( varargin )

inside of callback, use following syntax:

varargout = func_queue( @func, varargin )

where function

func_queue()

is responsible for interrupting if called multiple times and always caching last varargin so that it is not getting lost.

persistent returnFlag
if ~isempty(returnFlag)
   return
end
returnFlag=1;
...do something
returnFlag=[];

6 lines 🙂

@Arda – that’s certainly faster by about 10-fold, but would be less easy to maintain e.g. with multiple return points. Perhaps the challenge should be to achieve this with less than one line in the callback!

@Malcolm, it was just a joke. Sorry for the misunderstanding. Yet the code i wrote above does not work as i suspected..

@Arda
Your code worked for me in a WindowButtonMotionFcn relacing …doSomething with

 line(rand(1,10),rand(1,10));
drawnow();

That example simulates the effect of setting ‘Interruptible’ to ‘off’ and ‘BusyAction’ to ‘cancel’ – but via the callback rather than the object. If isMultipleCall() took up a large proportion of the execution time, an approach like this would be far better – the processor overhead for your code is tiny. Another tack is to clear the callback property at the start and reset it at the end of the callback routine – but if any error or ^C occurs while its cleared how would you reset it?

@Malcolm, you cannot clear the callback property value from within an executing callback, AFAIK. At least, it didn’t work a few releases ago and since it made sense I did not try again lately. The property appears to change, but then reverts to its previous value when the callback ends.

@Yair
That surprises me. You certainly can with a figure WIndowButtonMotion callback The code below runs just once after using set(figH, ‘WindowButtonMotionFcn’, @MyCallback).

 
function MyCallback(hObject, EventData)
set(hObject, 'WindowButtonMotionFcn', []);
disp('In Callback');
return
end

I also used a solution almost similar to Arda’s (using a persistent variable). After reading this post I opted for the isMultipleCall() because, like Malcolm very very wisely says, I had problems when internal callback errors (which were not fatal in my case) or Ctrl+C stopped the callback that I was controlling for recursive call. In this case the callback could not be run again unless I explicitly cleared all variables.

By the way, if the handle has properties ‘BusyAction’ and ‘Interruptable’ (like figure windows, uicontrols, etc.), setting ‘cancel’ and ‘off’ is always a choice. That should do the same…

This utility is very interesting, but due to the use of ‘dbstack’ it wouldn’t work in compiled applications.
Do you know of any easy workaround for that?
Thank you very much

@Michele – you could store a temporary flag in a persistent variable or the handle’s ApplicationData/UserData, or a variant of these. For example:

% Variant1
function myCallbackFcn1(hObject,eventData,varargin)
   persistent inCallback
   if ~isempty(inCallback),  return;  end
   inCallback = true;
   try
       % do something useful here
   catch
       % error trapping here
   end
   pause(0.001); drawnow;  % give all other events a chance to bail out above
   inCallback = [];
end  % myCallbackFcn1

% Variant2
function myCallbackFcn2(hObject,eventData,varargin)
   inCallback = getappdata(hObject,'inCallback');
   if ~isempty(inCallback),  return;  end
   setappdata(hObject,'inCallback',true);
   try
       % do something useful here
   catch
       % error trapping here
   end
   pause(0.001); drawnow;  % give all other events a chance to bail out above
   setappdata(hObject,'inCallback',[]);
end  % myCallbackFcn2

@Yair – Thank you very much for the quick reply, I’ll definitely give it a try.

This is very interesting. But how would you handle the case when you don’t want to bail out of the callback if it’s already executing, but you want to wait instead for the first instance to finish? The obvious solution of putting a polling loop does not work because the loop will keep Matlab from finishing the execution of the first instance. I can’t seem to find a solution to that problem!
Thanks!

@Rafael – if the callback’ed object supports the BusyAction and Interruptable properties, then setting these would be the easiest choice. Otherwise, you could preserve the callback parameters in some persistent data struct (e.g., a cell array) and set a timer object to run the callback function programmatically in a second or two.

Thanks a lot for the answer @Yair!
I’m not sure your solution of using a timer to re-execute the function will work for me. I have thought of that solution for a while, but let’s say you have two things that must happen in a particular order, and only the first one is the one that must be re-executed by the timer. How do I hold the execution of the second process until the first one has for sure executed? I get back to the polling loop problem! Would I have to convert all of my processes into timers that are constantly firing to check if it’s OK to execute in the right order? My whole system would be come a nightmare if I have to do that!

This has been a really useful post and has really helped out a Matlab GUI that I have.

I’m confused on one count though, and I’m sure this is just my lack of understanding of how Matlab runs behind the scenes. Why does this not work with a figure’s ResizeFcn callback? I would really like to have a custom resize, but it needs to be safe against re-entrancy. Currently, I’d handle this with a timer, but I’d rather not have to use that.

Is there a way to get this to work with the ResizeFcn?

Thanks.

Is there a reason why this function was removed from the Matlab File Exchange?

I prefer a simplified DBSTACK solution:

function flag = isMultipleCall()
   s = dbstack();
   flag = (numel(s) > 2) && (sum(strcmp(s(2).name, {s.name})) > 1);
end