We finally installed Xojo2013R2 and updated MBS to 13.2 today to test compile one of our apps. For some reason, this app now crashes during QA when our engineer continually resizes the app (while holding/dragging the corner of the app). It crashes around 10 seconds of continually resizing, which may point to some kind of a UI/threading issue in the app – but we have not investigated this yet.
Once/If we isolate the cause(s), we will create a test project with the feedback. This is one of our major apps and it is quite large, so it may take some time to track down the cause(s) and create a specific sample case. The crash log shows the app as “Test App” because we are under a NDA.
Ooops, as Sam had suggested, it is probably related to the TextArea. Specifically, it might be related to the scrollbars or control size being smaller than 0. Just for kicks, I created a brand new desktop app with only the TextArea control. I set the locking to all sides and resized the main window to make the TextArea smaller than 0. The app crashes with the debug message noted previously.
Our engineers have just confirmed that this bug also affects textfields, listbox, and password fields. There could be others, but we have stopped testing for now. It is important to note that the debug messages for some controls shows the following instead of the originally reported messages:
8/5/13 11:57:02.879 AM Test App.debug: Inconsistent set of values to create NSBitmapImageRep
We were not trying to set anything to smaller than 0 on purpose. With its properties locked, it just happens when we resize the main window. Either way, I hope this can be fixed as we normally don’t have textarea controls that are static in terms of size.
We could do that. In fact, our app has a min width and height of 1024x768. We make extensive use of container controls for the different views and each CC is uniquely laid out. To do find the least common denominator to work around this bug, I’m afraid the minimum width and height of the app will be almost as large as the screen itself (MacBook Pro 15 inch). Obviously we can rearrange the design/layout if it was our own app. But sometimes customers are very adamant about their layout designs. I won’t go into the rights/wrong or good/bad of app designs in terms of min app width/height, but I will say that we often create apps based on what our customers asks us to do.
Anyway, we also tried to come up with a subclass to prevent the affected controls to not go beyond 0. This prevents the app from crashing, but when we tested resizing the app quickly, the controls can sometime redraw much larger – going past the app’s right side or the app’s height.
Are you asking because this is a difficult bug to fix? I mean, it is pretty obvious that we can limit the size of a window/app as a workaround.
Doing something like this in the app’s resize/resized events prevents the crash, but it also creates a redraw issue as noted above.
if textarea1.width <= 0 then
textarea1.width = 0
if textarea1.height <= 0 then
textarea1.height = 0
I’m looking at it not from a support side as I can certainly redesign apps or keep this bug in mind for future apps/designs. I’m looking at this from a framework stability point of view since it can and will crash Cocoa apps. Sam has extensive skills in Cocoa and Xojo so it was obvious to him. Others, myself included, are not as skilled and would probably have taken a few hours or even days to track down bugs like this via a process of elimination, all the while thinking that it was our codes that was crashing our app.
My thinking is that if the controls are not meant to support negative values, Xojo should prevent controls from receiving negative values at the framework level. To be honest, I’m not even sure this is because of negative values as I don’t have access to the framework codes.
I guess we have become so reliant on RS doing the heavy lifting that we forget that things like this can happen. I can tell you that we have several apps that we never even considered having to think about control resizing issues beyond its smallest limitations in the past. I have to admit that we are probably using RS/Xojo incorrectly, so feel free to correct us.
I’m not trying to say that this bug is a show stopper (although it could be for some) and that it must be fixed immediately. I hope you understand that.
Anyway, thank you for looking into this and I hope to see a fix soon because we are not looking forward to changing the layouts of some of our apps.
Nona, There are probably hundreds of “bugs” like this waiting to be discovered, and will probably be hundreds as long as Xojo is a product. In any other framework you try, you’ll find a similar situation. Complicated software will always have a lot of bugs that don’t get exposed until someone exercises something just the right way to reveal the bugs. The best you can do is deal with it. Forums are great because if you can explain what’s going on, someone might have seen something similar and you can put your heads together to track down the problem and report it in a way that makes it fixable. Each Xojo release, you’ll see tens to a maybe a couple hundred little bugs fixed. It’s a process and that’s how it works.
I’m not seeing it in my apps, but it might be happening as I do get those annoying support e-mails “Your app is crap, it just crashes”… Like that’s going to help me figure out why it crashes for you and not others!