As far as I can tell SWT (and therefore DWT) Cursors do not support alpha masks (only 1-bit masks).  They also don't have any official way to do an end run around the API and use native calls if desired.

Fortunately the bits of state needed to work around it are public (the default constructor and access to the .handle property), though unintentionally so, it seems.

--bb

Bill Baxter schrieb:
> As far as I can tell SWT (and therefore DWT) Cursors do not support alpha masks (only 1-bit masks).  They also don't have any official way to do an end run around the API and use native calls if desired.
> 
> Fortunately the bits of state needed to work around it are public (the default constructor and access to the .handle property), though unintentionally so, it seems.
> 
> --bb

The JavaDoc of Cursor.handle:
the handle to the OS cursor resource (Warning: This field is platform dependent)
IMPORTANT: This field is not part of the SWT public API.

http://help.eclipse.org/help33/topic/org.eclipse.platform.doc.isv/reference/api/org/eclipse/swt/graphics/Cursor.html#handle

There are several fields/methods that are accessible but not part of the public SWT API. This is, because they need to access those from other SWT packages. Not nice, but at least in the JavaDoc its documented.

Frank Benoit wrote:
> Bill Baxter schrieb:
>> As far as I can tell SWT (and therefore DWT) Cursors do not support alpha masks (only 1-bit masks).  They also don't have any official way to do an end run around the API and use native calls if desired.
>>
>> Fortunately the bits of state needed to work around it are public (the default constructor and access to the .handle property), though unintentionally so, it seems.
>>
>> --bb
> 
> The JavaDoc of Cursor.handle:
> the handle to the OS cursor resource (Warning: This field is platform dependent)
> IMPORTANT: This field is not part of the SWT public API.
> 
> http://help.eclipse.org/help33/topic/org.eclipse.platform.doc.isv/reference/api/org/eclipse/swt/graphics/Cursor.html#handle 
> 
> 
> There are several fields/methods that are accessible but not part of the public SWT API. This is, because they need to access those from other SWT packages. Not nice, but at least in the JavaDoc its documented.

Ok, I saw the comment and took it to mean that it may become 'private' at some point.  Anyway, the fact that it is accessible makes it possible to feed it a cursor loaded from the native API, so I see that as a good thing.

My guess is that that SWT designers have not really given much thought to allowing raw access to underlying platform resources because in java it would just be too much of a pain for anyone to want to try to customize their app's behavior with native code beyond what's provided in SWT.   However, in D the situation is different.  It's not at all difficult to access native APIs, and you have a handy version() statement that lets you conditionally compile the code that uses those APIs.

Qt's Cursor API, for instance, has an offical (Windows-only) API that takes an HCURSOR:
  http://doc.trolltech.com/4.3/qcursor.html#QCursor-6

So what I'm saying is that it might not be such a bad idea to provide official ways to do some platform-specific things in DWT, since DWT is not constrained by the same forces that constrain SWT.

--bb