On 16/01/07, Jonathan Johnson <email@hidden> wrote:
On 16/01/07, Tomas Zahradnicky <email@hidden> wrote:
> Because I didn't want to include m files in the project and wanted to
> show it is possible from C.
Well, it certainly is possible, but it's not that pretty.
...
For even more fun times of beating multiple dead horses, you can even
load these methods up dynamically and call into Objective-C from PEF
applications <evil grin>.
If you're still using PEF then you're beyond help. :o)
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), 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.
However, even with the above code, it is
*infinitely* easier to simply write:
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).
-- Finlay
_______________________________________________
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
