Re: [platform-swt-dev] tag()/setTag() in the SWT-Cocoa implementation

[Kevin Barnes <krbarnes@xxxxxxxxxx>]

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>

To	platform-swt-dev@xxxxxxxxxxx
cc
Subject	[platform-swt-dev] tag()/setTag() in the SWT-Cocoa implementation

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