Re: [platform-swt-dev] How do I get at a Carbon constant?

[Silenio Quarti <Silenio_Quarti@xxxxxxxxxx>]

> Hi,
> 
> I was working on <https://bugs.eclipse.org/bugs/show_bug.cgi?id=263999>
> today and was able to get keycode derivation (via UCKeyTranslate)
working
> with newer, 64-bit-friendly APIs. To implement it, however, I need
a
> CFStringRef that¹s defined in Carbon.framework. I was able to use
> 'flags=const' to generate a C function to return the value but I can¹t
find
> a way to build the JNI lib without adding <Carbon/Carbon.h>
to os.h and
> '-framework Carbon' to the PI makefile.
> 
> It looks like we could do this dynamically with
> CFBundleGetDataPointerForName much like we do with
> CFBundleGetFunctionPointerForName for functions. Something like
> 'flags=dynamic,const' to trigger a symbol lookup instead of a function
> lookup. I can try modifying the JNI generator if this is worth doing;
I
> don't know if we'll need to do this more than once.

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.

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.

> 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?


Silenio