So I’ve managed to kill it pretty bad.
When something gets caught up and freezes, I can sort it out with the debugger. But I’ve managed to really fudge this one up.
I’m resizing a groupbox using the lovely AnimationKit, and I’m assuming this is where the problem lies. I have sorted out a safety net using a boolean called currentlyAnimating so that the app can’t start another animation on top of the one currently trying to execute.
This crash occurs in two spots. After animating, if I start resizing the window heavily (it doesn’t actually take too much effort) I get the crash; and if I try to resize the window while it’s animating.
I’m not very good at reading crash logs. Since one of the causes isn’t during the animation process I’m not sure where where I could breakpoint this to look into any issues. I’m hoping someone might be able to read the crash log and be able to tell me more about what’s actually going wrong.
Sure looks like a stack overflow and the crash logger only records a limited number of frames (500 I think).
But its so far off in the weeds doing this that I can’t even tell you where it started going wrong - its literally not in the stack trace.
Try this - disable all the animations first & see if you still have the problem.
It’s just something to try.
1.2 seconds expanding, 0.5 seconds closing.
Locking resizing was my backup plan for the during-resizing crash, but I didn’t want to have to do it if the crash wasn’t related to the animation at all. Still, for stability of the animation (since you’d be changing it’s final rect by resizing) I should probably lock it anyway.
[quote=93350:@Norman Palardy]Sure looks like a stack overflow and the crash logger only records a limited number of frames (500 I think).
But its so far off in the weeds doing this that I can’t even tell you where it started going wrong - its literally not in the stack trace.
Try this - disable all the animations first & see if you still have the problem.
It’s just something to try.[/quote]
I’ll disable them and see if I still crash it. I did some madman window-resizing testing when I was having issues with ListBox headers not resizing the way I wanted them to.
Just to add information, the crash log posted was from the post-animation window resizing crash.
Crrraaaap. I’ve just discovered that it has something to do with the fact that the GroupBox gets set smaller than the contents of it’s controls. It has a few labels, a checkbox, a textfield, and a text area inside it, but when you have no selection I resize it to 32px to maintain the label and the idea that it shows details, but hide all the stuff that would be empty. Also not a happy camper when it gets resized to offscreen because of Position locking, can position locks be enabled/disabled by code?
If this minor detail gets any more complicated I’m going to just scrap the idea >_>
I wonder if resizing those things down so far is whats having the effect ?
what if you make it so you can’t resize that group down to 0 width & height ?
I’ve significantly cut down on the crashes by enabling/disabling the locks dynamically so that the GroupBox can’t end up with a 0 height or end up offscreen. However I can still crash it when resizing the window.
It did crash much faster with animation enabled. Realistically a user wouldn’t see this animation as often, or resize as much as I’m testing here; but I like to run things into the ground to make sure that one person working really fast doesn’t accidentally crash it.
Also, window.resizable=false isn’t working; nor does the IDE flag do anything o.O
It sounds like it would be resize recursion. I have seen the crash happen as I’m making the window bigger and there are already min heights in place, so I’m not sure how I can prevent the crash.
Any thoughts on why not even the IDE flag for Resizable is disabling resizing?
Might be a pain, but you could use declares to examine the AutoResizeMask on each textView and its textContainer… then you could manually fix it… not a great answer I’m sure, but maybe that would provide enough info for Xojo to get the problem figured out and a temporary fix for your situation?
One thing I did see in one of the google results was a mention of Retina causing the OS to recalculate the Masks… no idea if that;s related or not. Do you see this happen with a simple textarea in a plain window? I wasn’t able to see it here on 10.7.5…
I’m not on a retina setup, so lord knows what kind of problems that’ll cause me.
Just created a few test projects and found out it does have to do with text areas inside containers as reported by that feedback case. Madman resizing on text areas not inside container controls works fine.
Found the issue with window.resizable=false. Needs Window.MaximizeButton to be false as well.
Probably would have thought of that if it wasn’t 2am when I was trying
EDIT: Okay, that only worked with IDE switches. It’s still not having any effect by code.
