Trying to be "clean" by not "polluting" your project with .m files and
instead tainting it with Obj-C runtime implementation details is
counter-intuitive. If you find it difficult for some reason (e.g.
you're one of those dinosaurs who hasn't moved to Xcode yet, or if
you're using some weird build system for legitimate reasons),
some legacy projects still require that...
then just create a bundle in Xcode and factor out your Obj-C calls
into
that. These days, it's getting harder and harder to avoid at least
some Obj-C in Carbon applications (WebKit, Core Image, etc only expose
an Obj-C API), and fearing that is irrational.
QuickTime has these problems too...
There're always reasons for doing it this or that way. Would you
believe I had an MPW project under Classic --- a Carbon plug-in for a
CFM Mac OS X only app that called IOKit and Cocoa? Hopefully the plug-
in moved to Mach-O a couple years ago... That days I had no option as
there was no free CFM compiler for Mac OS X or am I wrong?
I definitely agree that the easiest way is to drop an .m file into
the project and have Xcode handle it if you can do it.
However, even with the above code, it is *infinitely* easier to
simply write:
I'd say it depends on the metric you choose...
int WindowGetWindowNumber( WindowRef win )
{
NSWindow *win = [NSWindow initWithWindowRef:win];
int out = [win windowNumber];
[win release];
return out;
}
Except you can't *do* anything with a window number without relying on
SPI, and there's SPI for getting a CGSWindowID from a WindowRef
directly (without instantiating a special NSWindow hackhackhack for
representing non-Cocoa windows).
Indeed.
Tomas
_______________________________________________
Do not post admin requests to the list. They will be ignored.
Carbon-dev mailing list (email@hidden)
Help/Unsubscribe/Update your Subscription:
http://lists.apple.com/mailman/options/carbon-dev/email@hidden
