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

[Tom Schindl <listom@xxxxxxxxxxxxxxx>]

Hi,

CC me to the bug report tom.schindl@xxxxxxxxxxxxxxx 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
>>> nebula-dev@xxxxxxxxxxx
>>> https://dev.eclipse.org/mailman/listinfo/nebula-dev
>> _______________________________________________
>> nebula-dev mailing list
>> nebula-dev@xxxxxxxxxxx
>> https://dev.eclipse.org/mailman/listinfo/nebula-dev
>>
>>
>> !DSPAM:45ebbb4e199136697410382!
> 
>