Community
Participate
Working Groups
Created attachment 84425 [details] Snippet that illustrates the problem. Build ID: M20070921-1145 Steps To Reproduce: 1. Run the attached snippit on Windows. 2. Click the button in the upper-left-hand corner until the control animates to the right for the first time. (4 times on Windows Vista) 3. Without doing anything else try to move the horizontal scroll bars--all except the last are "frozen" in that they don't get the focus and one can't interact with them. Note that if you move the horizontal scroll bar or rezise the shell a little bit things are "un-frozen" More information: This bug is occuring in a more complex control than the snippet and is only on Windows. This problem does not occur on OS X or Linux. (Aside: On OS X I do see pixal corruption when tables are added into the scrolled composite and part of the table is off the screen--in this case table scrolling is done using the arrow keys with part of the table out of the cascading list's viewport.) I suspect that the ScrolledComposite control's setOrigin method is the root of the problem. Somehow it is not making the right native calls to do the same thing as a manual scroll bar movement. A workaround in the program (rather than via the mouse) would be very helpful to me. Best Regards...
This is probably related to bug 157058 which is ye olde bug; here's hoping my example makes it easer to develop a workaround and get this fixed.
Umm, it has been a few weeks is there some problem with the snippet? Can you reproduce this problem?
Duong?
I was able to replicate the problem on WinXP but it doesn't happen on Win2K.
When I changed the code to remove the animation and call setOrigin directly, the problem also occurs. cascadingList.setOrigin(origin.x + 10, origin.y); The odd thing was that some vertical scrollbars worked and some didn't. For some of the ones that do work, I can only select within about 3 pixels of it (near its edge). Selecting anywhere else in the scrollbar did not work.
Duong & Steve, I traced this pretty deep into the SWT bindings and I think it is a very low level problem, i.e., it is not a bug in the CascadingList--that is just the control that has uncovered the problem. I think it is in the C code but I can't figure out where?
I am able to make the problem happen by scrolling the horizontal scroll bar with the mouse. Once it happens, when I click off then back again, the problem goes away.
Fixed > 20080304 This was a crazy low level Windows operating system bug where WM_NCHITTEST was returning HTCLIENT instead of a hittest for the scroll bar. We detected the case and redrew the frame, somehow fixing the problem. It happens on XP and Vista but not 2000.
Is there a programmatic way to work around the problem (i.e., fix the snippet) or is this a case where we have to wait for Eclipse 3.4?
I first tried to work around the problem in your code. The problem is way down deep in Windows. I can't think of a way to do it. Are you shipping before 3.4?
