This sounds correct. Wow, you really have deeply understood how CompositeTable works. Please file a bug and I'll test on Win32. Is there anyone out there with a Mac?
Regards, Dave Orme ------- thanks a lot for the positive feedback! Always nice to hear :-) I have a more pickier problem I just managed to solve for GTK+ (I'll test things on Win32 asap) and I would appreciate a lot your ideas on this issue & my possible fix as this one gets deeper into compositeTable and SWT. But take your time! I really do not want to put more stress on you than you certainly already have :-( The issue can be experienced when you scroll the table by mouse-wheel very fast and you scroll the current row outside the viewport. It gets more frequent the more widgets are visible (the more complex a row is). The issue is that an arbitrary scrolled-in row (after the current row was scrolled out) gets focused and gets 'current row' - I clearly tracked it down to focusGained() in InternalComposite. I believe that the newly focused row is actually the one that got scrolled out and was repositioned to the top (and refreshed with new model-content). I believe that this is due to deferredSetFocus() that gets delayed a lot and gets executed only when the row was repositioned and scrolled in (on the top) again. My possible fix (tested for GTK) is to keep track of the control to focus delayedly (asyncExec) by setting the instance variable this.toFocus. Furthermore to clear that instance variable on row departure & fire a focusOut-event on the other hand. I try to prevent any deferredSetFocus() that would focus any control that was departed and is visible again, when asyncExec finally gets executed.
_______________________________________________ nebula-dev mailing list [email protected] https://dev.eclipse.org/mailman/listinfo/nebula-dev
