[
Date Prev][
Date Next][
Thread Prev][
Thread Next][
Date Index][
Thread Index]
[
List Home]
Re: [platform-swt-dev] tag()/setTag() in the SWT-Cocoa implementation
|
Kalugin,
Please file bug so that we can track and address this issue when work on the Cocoa port starts to pick up speed again.
We've been really busy with 3.4 and Cocoa hasn't had the attention it deserves lately.
thanks,
Kevin Barnes
Kalugin Mikhail <mikhail.kalugin@xxxxxxxxx>
Kalugin Mikhail <mikhail.kalugin@xxxxxxxxx>
Sent by: platform-swt-dev-bounces@xxxxxxxxxxx
05/18/2008 05:57 AM
Please respond to
"Eclipse Platform SWT component developers list." <platform-swt-dev@xxxxxxxxxxx> |
|
|
Hi,
Recently I met a weird problem with Display.getFocusControl() method:
it was failing with NPE on "OS.JNIGetObject(tag);" call (line 1083).
At first glance, this call doesn't do anything that can throw NPE.
After some investigations I've found the reason — tag wasn't an JNI
object reference. It was a natively set tag by Cocoa itself. I was
using NSAlert class which uses tags for the content view. So when my
application was asking for a focus control, SWT was encountering
NSAlert's window, asking for a tag in order to restore SWT's class and
then failing.
Regarding concretely this issue, the solution is simple: the
OS.JNIGetObject(tag); line can be surrounded by a try..catch block.
However, I think that problem has more deep roots. Really, why does
SWT use tag()/setTag() methods for storing JNI refs? Since Cocoa can
use tag field itself, it doesn't look as a secure solution. There are
methods for creating/reading/updating instance variables in Cocoa
object. So it would be possible to use some variable like
"swt_jni_ref" to store refs.
Please share your thoughts on this.
--
Kalugin Mikhail
_______________________________________________
platform-swt-dev mailing list
platform-swt-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/platform-swt-dev


