[
Date Prev][
Date Next][
Thread Prev][
Thread Next][
Date Index][
Thread Index]
[
List Home]
|
Re: [platform-swt-dev] How do I get at a Carbon constant?
|
On 2/13/09 7:00 AM, "Silenio Quarti" <Silenio_Quarti@xxxxxxxxxx> wrote:
> For now, since there is only one of these constants, you can mark the
> function as flags=no_gen and write the code in os_custom.c that uses
> CFBundleGetDataPointerForName.
Okay, will do.
> If Carbon gets used more and more and the functions we care are available
> in 64 bit, we should just link to "-framework Carbon" and include the
> header. Even though it is deprecated, I do not see it going away any time
> soon.
No, it won't disappear because there are still a lot of Carbon apps out
there that can't just suddenly stop working in 10.6.
There are lots of calls in Carbon and its sub-frameworks that are 64-bit
friendly. I know there's a push to put Objective-C wrappers around many of
them so you don't have to 'sully' your nice Obj-C code with pure C, but it
remains to be seen if that will happen.
>> Also, some of the routines I used couldn't be generated from the
>> bridgesupport files, so I also added some 'flags=dynamic' native methods in
>> OS.java. I also had to add a '#define <function>_LIB' in os_custom.h for
>> each of the new routines I added. Is that the way to do it?
>
> Which framework are the functions from? If Carbon, that is the way to go. If
> some other framework, we should check why they do not show up in the
> generator. There is no bridgesupport file for that framework?
The two new keyboard-related functions are in TextInputServices.h, which is
part of Carbon. UCKeyTranslate is now in UnicodeUtilities.h, which is
technically in CarbonCore in CoreServices.
There are a number of the Carbon-derived frameworks that don't have
bridgesupport generated for them yet. CoreServices, for example, has a
bridgesupport file but only for a subset of what's available. I don't know
if that's by design or oversight on the part of the groups that are
responsible for them.
-- Scott
