Hi Dave thanks a lot for the positive feedback that I'm on track with my understanding! :-) I tested the bug & patches on win32 and things seem to work. I just posted an entry to bugzilla with the appropriate patches and demo-snippet. I couldn't create a patch that does not rely on my former patch to arrive & depart so I posted the standalone (to show changes) & unified versions. The later one should be applied as this is the only one that creates compilable code.
Regards André > 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. > > > > !DSPAM:45e9bb75267201566610613! -- André Dietisheim Stv-Bereichsleiter Products Puzzle ITC GmbH Eigerplatz 4 CH-3007 Bern Telefon +41 31 370 22 00 Mobile +41 76 423 03 02 Fax +41 31 370 22 01 Puzzle ist Mitglied der ODF Alliance: <http://www.puzzle.ch/odfalliance/> _______________________________________________ nebula-dev mailing list [email protected] https://dev.eclipse.org/mailman/listinfo/nebula-dev
