GUIDE scrollfunction deleting figure

Hello, I have a question about my scrollfunction, I asked it here before but couldn't get a good response.

My question is this: I have a scrollfunction that works and works well. I have a gui I made in GUIDE with four axes, and the scrollfunction will change depending on the axes. My problem is this: depending on the rate at which I scroll, the figure can bug out and delete itself. After running some tics and tocs, I found the problem lies with how fast everything gets plotted.

When I scroll slower than it takes MATLAB to plot (~0.1/sec, meaning I can scroll upwards at 10 slices per second). When I scroll at a rate that would replot more than 10 times a second, it bugs out. THe reason I'm asking this, and just assuming its a MATLAB problem, is I have a separate duplicate programmatic GUI that does a identical process, with more or less the same code, that doesn't have this problem. I think the problem is within GUIDE.

Is this common, or is there a workaround? I tried to implement a pause of 0.1 seconds to try to get this bug to not occur, no dice. Regardless of what I do, whenever I try to scroll quickly, I have the figure deletion.

Thanks!

EDIT: Here are some segments of code from my UI. My scrolling function uses the mouse scroll wheel to go upwards and downwards in slices in a 3D matrix axially, sagittally and coronally by clicking on whatever GCA I want to sift through. My data consists of response data which I image in imagesc, and is again constructed in a 3D matrix. It represents a volume I export from a FEA utility.

I have attached the code to this question now as opposed to using gist.

These are the relevant graphics functions I employ at the moment. Besides that, here are some UI screenshots to help you get an idea of what my UI looks like:

GUIDE UI Active UI

And here is the error message I get when I scroll too quickly:

Error using drawnow
Error while evaluating DestroyedObject WindowScrollWheelFcn

Error using matlab.ui.Figure/set
Invalid or deleted object.

Let me know if you'd like me to upload anything else.

[matt dash]

Hmm, i've never heard of this, so i'd say no it's not common. It might be a side effect of something specific in your code. You might try reading about the "busy action" and "interruptible" figure properties. Maybe you can use those to prevent it from calling the scroll function too often.

[Geoff Hayes]

Brian - can you post a simple example of the code that is exhibiting this behaviour so that others can take a look?

[Brian]

I can post my code to github if you prefer. This is a highlight of how it works:

First, I click on the gca and save the tag to appdata. I then have a separate function that handles the scrolling, so when I activate the scrolling callback it gets routed to that function which I have saved in a functions folder (I like to keep it organized that way, even if i end up with a big folder of various functions).

My github code can be found here, and this is only the scrolling function. I call it in my figure function with this github link

If you'd link anything else, please let me know. I think, from things other people mentioned here, it could be a interrupt problem.

Cheers, BH

[matt dash]

You would need to post the "display" functions too... those are likely where the error is happening since they do the actual clearing/redrawing.

[Brian]

Will include, as well as some screen shots. I'll edit my main post so I don't have to edit the various responses.

[Geoff Hayes]

Brian - why not just attach your code using the paperclip button? When you attach only part of the code, it makes more challenging to determine where exactly the problem is..especially if we can't run it. That's why a sample GUI with some of your code that produces the same behaviour makes debugging (for others) that much easier.

[Brian]

I can do that, again I will edit my original post. I can't attach my data though, that I use to visualize, as even zipped its over 10MB.

Answer 1

[matt dash]

Ok, I'm not sure exactly what's causing your problem, but it is quite likely the cla resetting something that shouldn't be reset.

But that's tangential to the real cause of the problem, which is that you're clearing and completely redrawing the image every time you scroll the wheel. You don't need to do that, and more importantly you really don't want to be doing that, because as you can see it can lead to all kinds of unintended side effects.

What you really want do do is just be setting the cdata and alphadata of the existing image. This has two benefits: 1) it is much much faster than clearing and resetting. 2) it can't have any nasty side effects.

The only potentially tricky thing is that since you're using imagesc, you may need to be scaling your image data manually before plotting it. But that shouldn't take more than a couple lines of code to solve (basically just normalizing your data to match the size of the color map.

I have attached a demo function that shows how to make this work (minus the scaling... you can figure that out). Note how in the scroll function ONLY the cdata gets set. The image is only created once, in what is effectively the "openingFcn" at the top of the code. (Demo file doesnt show setting alphadata, but it works exactly like setting the cdata)

Side note: you know instead of using setappdata you can just store things in handles and retrieve them with guidata? This is generally faster (since all gui functions set/get handles already), and requires less code.

[Brian]

First off, thanks for the example, will look through it.

The reason I used cla was because I had times when the graph wouldn't redraw, it would draw over the last one (so I'd have the previous slice underlaying the new slice). I can take a look at imagesc, but would I have to clear the figure before redrawing manually, or can MATLAB do it for me?

Also, thanks for the handles tip. I used to use handles to store data, but I was taught later that its usually an example of "bad coding", is this true? I've never had a formal class on this, I sort of watched tutorials and learned to do this myself, so there are some nuances where I have to learnt he proper way to do it through questions like this.

Thanks though, seriously. Will attempt to make the changes today and see if I can get this solved.

[matt dash]

I'm not exactly sure what you mean by "clear the figure before redrawing manually". If you mean that you can use set sometimes, but other times you need to re-call imagesc to redraw the whole thing from scratch, my advice would be to use whichever clearing function makes the most sense. cla is going to delete everything that is a child of the axes, AND reset all the axes's properties to their default values (not to be confused with their initial values). If you just want to delete the image without resetting the axes, the better option is to use delete(<image handle>). If somehow things get out of whack so you end up with 2 images, that sounds like an error in your code that may be worth tracking down. But you could always use delete(get(axeshandle,'children')) to delete everything in the axes without resetting its properties. Just remember both cla and get(axeschildren,'handles') are going to be marginally slower than directly deleting an object whose handle you already have. Usually this doesnt matter, but in something like a scrollwheelfcn that potentially needs to run very quickly in succession, it can be important.

I think the handles issue is too obscure to have a clear cut right vs wrong... it's true that if you store a lot of large matrices, it'll start to get bogged down, and then it might make sense to store separate appdata's depending on what you need to access in each function. But if you're only storing a little information, it's simpler to have just one call of guidata than multiple getappdata/setappdata. And really the whole concept of a "handles" structure is just something GUIDE uses... and if anyone wants to be really picky about good vs bad coding, the good coding version of a GUI would not use GUIDE in the first place.

[Brian]

Thank you for your help in this. I think I have enough for now, and your advice has been very helpful.

I would like to learn to ditch GUIDE eventually, but the conveniences it provides (precise gui placement of buttons, etc) are hard to replicate.

Thats my problem though: thanks again for all your help!

Answer 2

[Image Analyst]

Exactly what is getting scrolled? Do you have a slider/scrollbar and are changing it, which changes some parameter which then causes a plot/graph/chart/image to change? Or do you have a scrollpanel for an image and you're scrolling the image (like in attached demo)?

Well, whatever it is or however you're doing it, maybe try putting in a "drawnow" at a strategic place to force update of the display. You might also want to totally reset the axes with a "cla reset" in between separate scroll operations.

[Brian]

I'll think about that, but I think it could be a interrupt problem with Java. I've been looking at some matlab-java memory leakage problems that are uncommon but probable, and I may try configuring the interrupt property.

These are some of the links, in case you're interested, that I think may be closer to the problem, because the error I get from MATLAB is:

Error using drawnow
Error while evaluating DestroyedObject WindowScrollWheelFcn

Error using matlab.ui.Figure/set
Invalid or deleted object.

[Image Analyst]

Again, exactly what is being scrolled? A slider? An image? A panel? A screenshot would help immensely here.

[Brian]

I'll edit my original post to include screenshots and I'll post my code. Sorry, probably should have done so in the first place.