I have a callback tied to a slider, and the callback takes a noticable time to execute. If I hold down the mouse button on the slider arrow, events are repeatedly generated, triggering the callback a number of times. Eventually, Matlab complains that I have hit the recursion limit. But I haven't actually hit a -recursion- limit as the callback is not recursive: it's just being queued many times.
I could increase the recursion limit but probably the same thing would still happen. So what I'd like to know is whether there is a way I can limit the number of pending events? I know one can set events to be interrupt or queued; I am using the default (queued) which is not in itself a problem; the question would be more one of whether I can limit the queue size ?
If not then what I'll probably have to do is enable/disable the slider itself; that's probably not going to lead to the best user experience, but it should solve the queue depth problem. -- "History is a pile of debris" -- Laurie Anderson
rober...@ibd.nrc-cnrc.gc.ca (Walter Roberson) wrote: > I have a callback tied to a slider, and the callback takes a noticable > time to execute. If I hold down the mouse button on the slider arrow, > events are repeatedly generated, triggering the callback a number > of times. Eventually, Matlab complains that I have hit the recursion > limit. But I haven't actually hit a -recursion- limit as the > callback is not recursive: it's just being queued many times.
Maybe setting the slider's BusyAction property to 'cancel' results in a satisfactory user experience.
In article <20080115122414.f59220c7.matthias.fruehwi...@joanneum.at>, Matthias Fruehwirth <matthias.fruehwi...@joanneum.at> wrote:
>On Mon, 14 Jan 2008 23:01:55 +0000 (UTC) >rober...@ibd.nrc-cnrc.gc.ca (Walter Roberson) wrote: >> I have a callback tied to a slider, and the callback takes a noticable >> time to execute. If I hold down the mouse button on the slider arrow, >> events are repeatedly generated, triggering the callback a number >> of times. Eventually, Matlab complains that I have hit the recursion >> limit. But I haven't actually hit a -recursion- limit as the >> callback is not recursive: it's just being queued many times. >Maybe setting the slider's BusyAction property to 'cancel' results in a satisfactory user experience.
Thanks, that was a good thought; unfortunately in practice it didn't seem to make any difference for me.
What I have done now is put a persistant flag variable in the callback routine; when it is set them I am already executing that callback so I then just return before doing any work. Could be a problem if I ever crash in that callback routine (because then it wouldn't be cleared), but I'll worry about that some other time. -- We regret to announce that sub-millibarn resolution bio-hyperdimensional plasmatic space polyimaging has been delayed until the release of Windows Vista SP2.
> What I have done now is put a persistant flag variable in the callback > routine; when it is set them I am already executing that callback > so I then just return before doing any work.
Nice workaround. I played around a bit after reading your post but couldn't come up with a working solution. So let me tell you what does not work!
I tried clearing the callback in the beginning of the function, and then restoring it before function terminates. Tens of callbacks were queued anyway. Maybe Matlab takes a copy of the callback property when mouse is clicked and keeps using that. It's quite unexpected if you ask me.
However here is something that may be of use to you. In my machine, if the callback function is involved in heavy computations, additional callbacks are instantiated after first function releases the CPU or something (purely empirical observation here). So inserting the tiniest pause before resetting your persistent flag may smooth things a little further.
Sorry for writing all these observations with no foundation what so ever. Hope they help anyway.
"Walter Roberson" <rober...@ibd.nrc-cnrc.gc.ca> wrote in message news:fmgpl3$e2v$1@canopus.cc.umanitoba.ca... >I have a callback tied to a slider, and the callback takes a noticable > time to execute. If I hold down the mouse button on the slider arrow, > events are repeatedly generated, triggering the callback a number > of times. Eventually, Matlab complains that I have hit the recursion > limit. But I haven't actually hit a -recursion- limit as the > callback is not recursive: it's just being queued many times.
> I could increase the recursion limit but probably the same thing > would still happen. So what I'd like to know is whether there is > a way I can limit the number of pending events? I know one can > set events to be interrupt or queued; I am using the default (queued) > which is not in itself a problem; the question would be more one of > whether I can limit the queue size ?
> If not then what I'll probably have to do is enable/disable > the slider itself; that's probably not going to lead to the best > user experience, but it should solve the queue depth problem. > -- > "History is a pile of debris" -- Laurie Anderson
The most common cause of this is that your callback is doing something that lets more events get processed and these events trigger another copy of the callback. When this happens, you get multiple copies of the callback piled up on the stack until you hit the recursion limit.
The most common thing that callbacks do that cause events to be processed is to call "drawnow". You need to do this if you want to get a figure window to repaint, but it lets all events through, including more mouse events.
The simplest workaround for this is to pass the "expose" argument to the drawnow function. This will tell it to process the events that are needed to redraw the figure window, but leave all of the other events queued up until the callback is done.
Unfortunately, it is possible that the events are getting processed as a side effect of something other than the drawnow command. In that case there isn't really a simple fix.
> >> I have a callback tied to a slider, and the callback takes a noticable > >> time to execute. If I hold down the mouse button on the slider arrow, > >> events are repeatedly generated, triggering the callback a number > >> of times. Eventually, Matlab complains that I have hit the recursion > >> limit. But I haven't actually hit a -recursion- limit as the > >> callback is not recursive: it's just being queued many times.
> >Maybe setting the slider's BusyAction property
to 'cancel' results in a satisfactory user experience.
> Thanks, that was a good thought; unfortunately in practice it didn't > seem to make any difference for me.
> What I have done now is put a persistant flag variable in the callback > routine; when it is set them I am already executing that callback > so I then just return before doing any work. Could be a problem if > I ever crash in that callback routine (because then it wouldn't be > cleared), but I'll worry about that some other time. > -- > We regret to announce that sub-millibarn resolution bio- hyperdimensional > plasmatic space polyimaging has been delayed until the release > of Windows Vista SP2.
Have you tried checking the m-function stack (see dbstack) and return in case the function is already listed ? If it works, it should prevent stack pile-ups, without the problems associated to additional persistent flags.
|
