Carbon or Cocoa?

[Michel_Bujardet]

@80773:@Markus Winter

It is not about the age of the machine, it is about how long you support the OS. XP was supported for 14 years, so my father-in-law (a switcher) is understandably unimpressed.

What I was saying is that computers themselves can work reliably for a long time, even with programmed obsolescent prone Apple. And there are sometimes very little reasons for users to objectively upgrade, when the machine does what they want.

I am not so sure MS kept XP out of sincere generosity. Could have been more because they failed to find a decent replacement before Windows 7. Vista being the loudest failure of all.

Could be because MS learned from Apple, but today seems to me forcing buyers to purchase Metro apps in its store, which in turn is a nightmare environment for developers, is far worse than any Mac OS X evolution. MS seems intent to move to its new platform no matter what, in spite of the tremendous software base. Talking about imposed obsolescence

[Rick_Araujo]

[quote=80702:@Eric Williams]To clarify a few points in this thread:

• Carbon is present in 10.9 and still works just fine. It has been deprecated by Apple, though, and no major additions or fixes are planned.[/quote]

Just to clarify one point. Carbon in frozen… better is melting.

Carbon is 32 bit only and will have no 64bit counterpart. So, you will not be able use a newer x64 compiler and x64 framework using Carbon, ever.

Apple will increasingly dismantle Carbon removing old deprecated parts, example, since 10.8 the Open Transport API was deleted. More will follow until total removal.

Advice: Upgrade your apps as soon as possible, with some tranquility, or be prepared for hurry and despair in the future.

[Joe_Ranieri]

@80777:@Rick Araujo

Apple will increasingly dismantle Carbon removing old deprecated parts, example, since 10.8 the Open Transport API was deleted. More will follow until total removal.

Open Transport was informally deprecated on 10.0 and formally deprecated on 10.4. I personally don’t expect Apple to remove Carbon until it removes support for 32-bit.

[Jim_Smith]

@80751:@Michel Bujardet

Frankly, it does not cost too much to keep a 10.6 version on the shelf. Should all efforts be put into a new compile for it instead of pursuing 10.9x and soon XX ? I doubt it.

If I wanted (needed) to make a version of an application for 10.6 can I use the source I have been using with the current release of Xojo? Are there something that would need to be change, like was SQLite supported in 2013 version of Xojo?

[Paul_Lefebvre]

@80788:@James A Smith

If I wanted (needed) to make a version of an application for 10.6 can I use the source I have been using with the current release of Xojo?

Opening a current project in an older version of Xojo is not officially supported, although it often works fine.

@80788:@James A Smith

Are there something that would need to be change, like was SQLite supported in 2013 version of Xojo?

SQLite has been available (as RealSQLDatabase) since 2005 Release 1. SQLiteDatabase was added in 2013 Release 1.

[Rick_Araujo]

@80779:@Joe Ranieri

I personally don’t expect Apple to remove Carbon until it removes support for 32-bit.

Maybe you are right, and maybe that can occur at some unknown point in time in the next 4 years.

[Thomas_ROBISSON]

Graphics animation are still quickest when build in Carbon than in Cocoa.

[DaveS]

@80934:@Thomas ROBISSON

Graphics animation are still quickest when build in Carbon than in Cocoa.

True,… but as I am painfully finding out, there are ways to compensate. plus Cocoa allows you to do graphics things not easily available in Cocoa

[Norman_P]

Cocoa does very nice compositing that Carbon doesn’t

[Kenneth_Reed]

Bob Keeney: Thanks for warning; I do use four threads for TCP communication and some for computation. These threads are “owned” by a method that spawns them and takes care of them. They don’t communicate with the UI. Suppose I want to trigger a MsgBox from inside a thread to help debugging. I assume that won’t work. Correct?

[Michel_Bujardet]

@83973:@Kenneth Reed

Suppose I want to trigger a MsgBox from inside a thread to help debugging. I assume that won’t work. Correct?

No, it will not work. But you may want to read this taken from the MsgBox documentation page, which also provides a solution :

Notes You should avoid using MsgBox for displaying debugging messages. The displaying of the Message Box will alter event order and may give unexpected results. Instead use the Debugger, System.DebugLog or your own logging mechanism.

[Bob_Keeney]

@83973:@Kenneth Reed

Suppose I want to trigger a MsgBox from inside a thread to help debugging. I assume that won’t work. Correct?

Correct, that will trigger a ThreadAccessingUIException. Take a look in the examples, there is a Tasks example for threading that will accomplish what you want. Since Timers always fire on the main thread you can use their Tasks example to add a message box. Keep in mind that it won’t stop the thread but you can at least report something.