Re: [nebula-dev] [CompositeTable] fast scrolling behaves oddly

["André Dietisheim" <dietisheim@xxxxxxxxx>]

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/>