timer not always running

I have an event listener callback. In that callback I run the following code:

    disp('I ran')
    t = obj.timer; %obj is instance of handle class     
    stop(t);
    set(t,'TimerFcn',@(~,~)obj.resize2(h,event_data,axes_I,count,new_xlim,new_position));
    start(t)

    obj.timer = t; %Hold onto new timer so that it doesn't get deleted and executes

In resize2():

   disp('I ran too!')

Previously I've done: t = timer; t.StartDelay = TIMER_START_DELAY; obj.timer = t;

I'm seeing code that indicates that the callback ran, but not the resize2() function. I'm seeing something like:

   I ran
   I ran
   I ran
   I ran
   I ran too
   I ran
   I ran
   I ran too
   I ran
   I ran

The way the callback code is setup, I want there always to be at least one call to resize2, following any calls to the callback. Any thoughts on why I am not seeing this?

Thanks, Jim

[Geoff Hayes]

Jim - out of curiosity, why do you start what appears to be a "single shot" timer that just calls the resize2 function? Why not replace all the timer code with just

 obj.resize2(h,event_data,axes_I,count,new_xlim,new_position);

The use a matlab timer object link has the following note

The specified execution time and the actual execution of a timer can vary because timer objects work in the MATLAB single-threaded execution environment. The length of this time lag is dependent on what other processing MATLAB is performing. To force the execution of the callback functions in the event queue, include a call to the drawnow function in your code. The drawnow function flushes the event queue.

How often is your event listener callback firing? Perhaps faster than the timer callbacks can be processed?

It would be interesting to know which "I ran" output that the "I ran too" corresponds to. (What I mean by that is, does the first "I ran too" (from above) correspond to the first "I ran" or the fourth?)

[Jim Hokanson]

Hi Geoff,

Thanks for the great questions! I'm using a different approach now and my problem has gone away, but I'm still curious as to why I see this problem.

To answer your questions. I have a process that takes a long(ish) time to run. The callback is being executed many times. I don't want to execute every callback, because this would take a potentially long time.

Alternatively, I could check if I am currently executing a callback, and ignore the calls to resize2. This is being done in some other code on the FEX, but it also means that I won't always run the latest callback. If I could drop callbacks, I'd rather drop earlier ones than later ones.

To drop earlier calls, and not later calls, I am using the timer approach. Every time the callback executes, I am essentially telling the timer (I think) - "wait a little bit longer until running"

Each "I ran too" should correspond with the last "I ran" statement - so the first "I ran too" should correspond with the 4th "I ran" statement.

Oops, I also noticed some abbreviations to the code that make all of this not-obvious. I've added some code above to make it obvious that I'm holding onto the timers between calls.

Make sense? Any insights or suggestions?

Thanks, Jim

[Geoff Hayes]

Hi Jim - That's an interesting approach which makes sense. I still wonder about the properties for your timer - how is it initialized (period, etc.)?