Summary: | SWT Cursor Source and mask are flip-flopped (1GJ80FZ) | ||
---|---|---|---|
Product: | [Eclipse Project] Platform | Reporter: | Veronika Irvine <veronika_irvine> |
Component: | SWT | Assignee: | Silenio Quarti <Silenio_Quarti> |
Status: | RESOLVED FIXED | QA Contact: | |
Severity: | normal | ||
Priority: | P2 | CC: | andre_weinand, hudsonr |
Version: | 2.0 | ||
Target Milestone: | --- | ||
Hardware: | All | ||
OS: | All | ||
Whiteboard: |
Description
Veronika Irvine
2001-10-11 14:23:23 EDT
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. |