Community
Participate
Working Groups
From eclipse corner post by Randy Hudson: I was trying to create my own cursor when I noticed that all of the resources that ship with Eclipse are switched. BMPs with the "_source" suffix are actually masks, and those with the "_mask" suffix are actually the source. This is quite confusing. The constructor: public Cursor(Device device, ImageData source, ImageData mask, int hotspotX, int hotspotY) is actually treating the source as the mask, and the mask as the source. I also tried to create a Cursor with just a source and no mask, but: new Image(null, source, mask).getImageData() is returning an Image with depth of 32, even though both source and mask are 1-bit depth. I could not figure out how to get a valid ImageData for creating the cursor this way short of completely building the data in hex. Could someone show me how? I would like to just load a transparent GIF as a cursor. The class Image is treating masks and sources correctly. Here is my test case. Notice that the cursor and the CLabel disagree on what the final Image should look like (The cursor *appears* correct, but that is because the resources are swapped). Try "bottom_source.bmp" for an even better example. The resources from the org.eclipse.ui/icons were copied into a default package for use with this test class: //Default package import org.eclipse.swt.widgets.Shell; import org.eclipse.swt.widgets.Display; import org.eclipse.swt.graphics.*; import org.eclipse.swt.SWT; import org.eclipse.swt.custom.CLabel; public class CursorTest { static Shell shell; static Image image; static Cursor cursor; static ImageData source; static ImageData mask; static { source = new ImageData( CursorTest.class.getResourceAsStream("stack_source.bmp")); mask = new ImageData( CursorTest.class.getResourceAsStream("stack_mask.bmp")); image = new Image(null, source, mask); image.setBackground(new Color(null, 0,0,255)); cursor = new Cursor(null, source, mask, 0,0); } public static void main(String args[]){ shell = new Shell (); shell.open(); CLabel label = new CLabel(shell, 0); label.setBounds(10,10,200,200); label.setBackground(new Color(null, 100,200,0)); label.setImage(image); label.setText("foo"); label.setCursor(cursor); shell.setLocation(100,30); shell.setSize(800,600); Display display = Display.getDefault(); while (!shell.isDisposed ()) { if (!display.readAndDispatch ()) display.sleep (); } } } NOTES: Randy Hudson (8/29/2001 11:15:04 AM) Although duplicate 1FRSOOR was moved to inactive in November, this should be addressed. In the very LEAST, you could name the parameters correctly on the constructor. ITPUI should probably rename their .GIF resources to the correct names, since that can be confusing too. Even though I was aware of the bug, I spent about 3 hours trying to make one cursor. I was using 2 GIF files as the source, both were indexed with a Palette of just two colors, so they were 1-bit. No matter what I did, the area in the source that was inactive (masked out) was showing up as XOR instead of transparent. I thought this was a problem with the mask, but when I finally switched to using a .BMP file for the source, with the same mask, the problem went away. I also tried providing just one ImageData parameter. I did new Image(source, mask).getImageData(). The imageData that got returned had a depth of 32, even though both source and mask had depth of 1. There are comments in Image.getImageData() about returning something compatible for Cursors, but it appears this is not working correctly.
PRODUCT VERSION: 1.0 133
McQ to cause a vote on fixing this.
I did attempt to get this fixed, but was unable to convince anyone that the change was justified. In the last release, we didn't even document the behavior. I'll at least attempt to get the javadoc fixed to match reality.
*** Bug 4415 has been marked as a duplicate of this bug. ***
This API is going to have to stay the way it is now. We can't fix it without breaking existing R1.0 (and R2.0) plugins, so it's just going to have to be the way it is. I believe the correct way to "fix" this problem is to implement a new constructor taking an arbitrarilly different argument (for example, add a last argument which is the "versionInfo" which must always be zero, or some such) but which has the existing arguments in the correct order, and then mark the current API as deprecated as of R3.0. SN to do this once R2.0 ships.
Regardless of introducing a new Contructor, the old constructor should have its parameters re-labeled, and the JavaDOC updated to note the problem. It looks like OS.createCursor is probably similarly swapped, but that isn't API anyway.
Assigning to SSQ. Can we just fix this to be the "wrong order" and forget about the new constructor for now?
The new constructor has been added. We are not changing anything in the old one. We made the old constructor as consistent as possible between platforms. App code should use new constructor to get maximum consistency.