Community
Participate
Working Groups
Created attachment 200928 [details] Fedora 8 GTK 32bit behavior The SWT API behavior differs greatly when running on Mac OS X: Calling toDisplay(x, y) on a Control, e.g. a List, returns different y-Coordinates for the converted point, as soon as the Scrollable is scrolled to display a list item. See the attached screenshots for further information: I used Fedora 8 GTK 32bit and Windows 2008 32bit as reference platforms to show the "normal" behavior. In addition to that I started the same application on Mac OS X 10.6 Cocoa. I "produced" the output as follows: - launch the snippet application, re-size it to show only e.g. 4 items, place it to the top (to avoid too big screen coordinates - easier to read and understand ;) ) - select the first item 0 and successively select item n + 1 and so on - as soon as the scrolling starts (In my case item 3) the behavior differs on Mac OS X
Created attachment 200929 [details] Windows 2008 32bit behavior
Created attachment 200930 [details] Mac OS X 10.6.8 64bit Cocoa behavior
possibly related to Bug 353905 Markus, could you pleasepost your testcase snippet here ? are you always calling toDisplay() with the same x,y ?
Created attachment 200959 [details] The code fragment I used to reproduce the issue. Yes, I am always calling it with the same coordinates. In addition thank you for the clarification on bug 353910!
Note that control#toDisplay will convert a location relative to client area of the control to the screen. if the origin of the client area is moving when you scroll the control, that 0,0 is not at the same place (relative to the origin of the client area 0,0 is moving). try changing your snippet this way: Rectangle ca = list.getClientArea(); System.out.print("| Client Area: " + ca); System.out.print(" | list.toDisplay(0, 0): " + list.toDisplay(ca.x, ca.y)); yes the result consistent now ?
*** This bug has been marked as a duplicate of bug 333375 ***
note that if - toDisplay x,y are relative to the client area - and the client area does scroll (bug 333375) then this bug is not valid. the key is not look at the values of x,y in the client area, as long as it "works", then there is no bug.
