Hi, CC me to the bug report [EMAIL PROTECTED] and describe what behaviour I should see/not see.
Tom André Dietisheim schrieb: > great!! My (possible) fix is still on my harddrive. I'll post the > appropriate patch to bugzilla today and I'll notifiy ya. Thanks for the > testing! > > Greetings > André > >> yeah. since yesterday ;-) Should I check out from CVS and do what >> afterwards? >> >> Tom >> >> David J. Orme schrieb: >>> 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 >> _______________________________________________ >> nebula-dev mailing list >> [email protected] >> https://dev.eclipse.org/mailman/listinfo/nebula-dev >> >> >> !DSPAM:45ebbb4e199136697410382! > > _______________________________________________ nebula-dev mailing list [email protected] https://dev.eclipse.org/mailman/listinfo/nebula-dev
