Classic to Cocoa: Finding Equivalent Functionality

[Emehr]

Greetings all,

Having been inspired to ditch Classic development altogether and move to Cocoa, I find that the biggest time-eater is finding an equivalent way of accomplishing something in Cocoa that I could do with my eyes closed in Classic.

For example, drawing a portion of one image into a portion of another: in Classic it was CopyBits(); in Cocoa (I found out after much experimentation) it's the NSImage method drawInRect:fromRect:operation:fraction. There are probably other ways but I haven't explored them yet (suggestions welcome :) ).

Recently I discovered another one: Whereas Classic had Ptr and Handle types, I understand that in Cocoa that functionality can be had in the NSMutableData class (I haven't tested it yet). To obtain a pointer to the data, simply call the -mutableBytes method. From there the data can be manipulated using the standard char pointer (if I understand correctly).

For those who made the move from Classic, can you think of any other Classic->Cocoa equivalencies that had you stumped?

[LongJumper]

One of the differences between C/Carbon and Obj-C/Cocoa is that, well, they are a different. Trying to do something "equivalent" isn't always the best way to do it. For example, if you were going to make a game using NSImage's drawInRect, I'm going to go ahead and guess it'd be ungodly slow. Pushing pixels to the screen will probably be OpenGL's job, that's more or less the standard. Most of the "game" stuff won't be using too much Cocoa, that's just the part with interfacing the game with OSX.

Basically, if you're going to use Cocoa, think of new ways to do things, not trying to make your old ways work. :P

[AnotherJake]

Yes, equivalency is not really the goal. Like for instance, you won't miss Ptr and Handle. And I wouldn't worry about wrapping all your memory in NSData (or NSMutableData), unless you actually have a need to. malloc() and free() are your friends on OS X. File routines are another area to let go of from Classic, if you were using the Toolbox ones. Mixing standard C file routines (fopen(), etc.) in with Cocoa ones is perfectly acceptable.

[Emehr]

My goal here is to try and ease the initial pain of porting over my Classic code. My structures make heavy use of Pascal strings (Str31 and Str63 typically), Rect, Point, Ptr and Handle types (among others) and I'm looking for equivalent functionality just to get it working. From there I can optimize and what-not.

I was messing with my Cocoa project "scratch pad" (which I use to try stuff out) and for grins I stuck a Str63 string in my interface and initialized it in the -awakeFromNib method. Did not expect it to compile at all but it did! Are the MacTypes.h definitions officially supported or should I not get too comfortable with them?

[OneSadCookie]

You should not use Pascal strings, as they do not deal correctly with non-English characters. NSString and CFString replace them.

Rect and Point are often replaced by NSRect, NSPoint, CGRect, CGPoint, HIRect and HIPoint replace them, so there's no major headaches there. Ptr is just a stupid name for void*, and Handle is a complete anachronism (use void* instead).

Of course, chances are your Classic code isn't object-oriented, so you're going to need a complete rewrite for Cocoa anyway. Don't get too attached to anything you've done before.

[AnotherJake]

Ptr is just a stupid name for void*...
Yeah, but Ptr and void* are (ahem, *were*) not the same thing... I don't miss those days.

All the Pascal strings should be done away with for sure. I think the C stdlib implementations of the string functions are up to date and use UTF8, so they should be safe too (as always, I could be wrong about that).

[OneSadCookie]

Avoid the C standard library too. It doesn't (by default? ever?) use UTF-8, so isn't any more safe for non-ASCII text than a Pascal string. Use NSString or CFString.

[AnotherJake]

Ah, I found it. Here's where I got that impression: http://www.cl.cam.ac.uk/~mgk25/unicode.html#c

[Fenris]

Besides, Pascal strings are deprecated in 10.5.

[Emehr]

Thanks for the replies. I appreciate the input. Is there anything in the Cocoa text classes that can tell me where a point is within the range of text (returned as an offset or index into the characters)? In Classic it was TEGetOffset(), which worked in my Carbon port of my code. Specifically, I need to know where (in a block of text) the mouse is hovering.

[EDIT: I think I found it. NSLayoutManager has a glyphIndexForPoint:inTextContainer method that should do the trick]