OSX 10.8.4 - a quiet disaster.

I posted another topic about problems I had with 2012R2 and OSX10.8.4
Well, things are worse than that. For me at least - 10.8.4 is pretty much a quiet disaster: I don’t know what they changed, but bad things are happening.

This post probably isn’t asking for help: I don’t think there’s any help to be had.
It’s probably more so that when someone else arrives here with the same symptoms, they can at least know ‘its not just me’

Over the last year or two, in preparation for Cocoa, I changed my drawing code so that it occurs in the Paint event, and switched from Refresh to invalidate throughout.
This has been working fine in Cocoa and Carbon from 10.6 through to 10.8

This year, I took the plunge and shipped my well tested Cocoa app , built with 2012R2
And soon after heard from a handful of people on 10.8.4 where it randomly crashed.

Oh no!. Right… I’ll build the carbon version for them. Thats been working for years.
Nope. Carbon app built in 2012R2 seizes up after a minute or two when doing heavy drawing.

So I had to pull my 2013 launch, and revert back to the Carbon only 2012 edition, build with RB2009
That appeared to stabilise things.

But now I hear (and can see) that some bits of the app, (which use Invalidate to cause labels to update in response to a slider control), don’t repaint.
The slider works, but the labels lie.

This means that under 10.8.4 I don’t currently seem to have any compiler or target platform that I can build a reliable app with.
Im told Carbon is deprecated in RB2012, and in OSX, which I was expecting eventually, but only after Cocoa had at least a year in release status under its belt.

So Im forced to take a leap of faith and try a Cocoa only build using Xojo, which is to all intents and purposes untested by me.
Worrying times.

Carbon is dead. Apple did not create a 64-bit version of Carbon and deprecated the entire system in 10.8.
Cocoa only works in the latest Xojo.

Cocoa wasn’t ready in Real Studio, but it is in Xojo. I’d expect that the issues will disappear once you recompile with the latest version.

I don’t understand this statement since there has been a newer version of the IDE than what you’re using for some time now.

I think you’ll be pleasantly surprised at how well your app will function once compiled in (the non-beta version of Cocoa that comes with) Xojo.

Jeff:

do you have made tests with an external Mt Lion (10.8.4) with Xojo 2013r2 installed ?
If you get the same results: sorry.
But you can get surprises.

My disc of starting 10.8.4 is syphilitic (bad). I get better results with an external 10.8.4 hard disk.

Alternate search. Follow first Kem advice.

Hi Jeff,
Sorry to hear this. I think you’re going to have to try to find a way to narrow this down. Getting the testers to copy and mail you back the crash reports will go a long towards illustrating where the crash is occurring. Do you do any error capturing?

In our apps we capture any RS runtime errors and then ask the user if they want to send this information back to us. It doesn’t pinpoint exactly where the error is, but it does tell us the methodname, the call stack and the error. From here, I can often walk through the code and see what I previously overlooked (although not always).

Currently we have 2 apps on sale that were built with 2012r2.1 and are Cocoa apps, one of them should be updated any day now when Apple complete their review and the other I’m currently working on.

Both of these apps are graphics/photo apps and together we’ve shipped 1000s of units. They’ve both got their own issues, but none related directly to 10.8.4.

Is your application Sandboxed? Do you use SSBs?

Hi Sam,
Slightly off topic, but How do you implement capturing runtime errors? Is there an over arching way or do you build it in to each piece of code?
Thanks
Hamish

The short of it is to use app.unhandledexception event. Then look at the ‘stack’ array property of the exceptionError to figure out the stack trace.

Thanks!