Hi Tom, yes, that's what I did (checked out the latest cvs, inserted my changes, created a patch.. I just checked out the latest cvs, applied my patch and did not have any troubles. Did you apply the 2nd patch (not the first one in the list. I included this to show only what changes I inserted. The current changes rely another patch I did in https://bugs.eclipse.org/bugs/show_bug.cgi?id=173558 and I therefore put a second patch, that includes both changes (patch to bug 173558 & the current bug)
Greetings André > Hi Andre, > > I'm having problems applying your patch against the latest checkout from > nebula. I get merging conflicts all over the InternalCompositeTable. > Does the patch apply for you cleanly on a checkout from cvs? > > Tom > > André Dietisheim schrieb: >> Hi tom >> >> I just checked my patch and a demo-snippet into bugzilla: >> >> https://bugs.eclipse.org/bugs/show_bug.cgi?id=176466 >> >> I couldn't add you to cc's as your list-email was not accepted. Thanks >> for the testing!!! >> >> Regards >> 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:45ed45f385491811889055! -- 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
