Hi Dave! hope you're back up on feets again! You're welcome! :-)) I'd really like to use it in my client (I am coding sort of highly extended database browser for the swiss railways) to replace the current tableViewer so I'll have to code until its bugfree and has all features I need. But I admit your table is very intersting stuff!
I posted the next bug + patch I found when testing on my gtk-box @ home. I hope you don't mind me refactoring a bit, it helped me best to understand the code and I think its valuable for anybody trying to understand the code. Greetings André > No problem. I've been sick so I haven't been responding as quickly as > normal. Thanks for putting this in Bugzilla! And thanks for the patch. I > have to look at the code but what you're discussing feels like it's > probably the right solution. > > Thanks again! > > Dave > > Message: 1 > Date: Sat, 03 Feb 2007 15:44:35 +0100 > From: Andr? Dietisheim <[EMAIL PROTECTED]> > Subject: Re: [nebula-dev][compositetable] bug: changes in topRow == 0 > get lost > To: Nebula Dev <[email protected]> > Message-ID: <[EMAIL PROTECTED]> > Content-Type: text/plain; charset=utf-8 > > Sorry for posting here, I found the bugzilla entry > > https://bugs.eclipse.org/bugs/show_bug.cgi?id=164419 > > and updated the bug. > > On Fri, 2007-02-02 at 10:16 +0100, Andr�� Dietisheim wrote: >> Hi Dave >> >> I'm almost there with my changes in GridRowLayout. It works - beside 1 >> bug - on the snippets of eclipse.org/nebula and I'll have to catch up >> with the changes in cvs (AbstractGridRowLayout). >> I found a bug that occurs when you have the table showing the first >> row (topRow == 0). It does not fire a row focus event and the symptom >> is that changes in the first row get lost (change any cell, scroll >> down and up again. notice that your changes are lost). My fix >> consists of changes to >> >> - fireRequestRowChangeEvent() >> >> I changed: >> >> if (rows.size() < 1 || currentRow < 1) { >> return; >> } >> >> to >> >> if (rows.size() < 1 || (currentRow < 1 && topRow != 0)) { >> return; >> } >> >> and the sam in >> >> - fireRowDepartEvent() >> >> I post this stuff here because I'm not completely sure what your test >> is for and if my change does not have other unwanted consequences. >> If I understand things right, currentRow is the offset of the >> currently focused row to topRow, which is the absolute position of >> the first row shown (in the table) in the model (ex. swtCommitters). >> Explained like this, your check avoids firing focus related events >> when the 'focused' row moves out of the visible rows (rows). Am I >> right? >> >> Regards >> Andr�� >> >> _______________________________________________ >> 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 > > > End of nebula-dev Digest, Vol 11, Issue 3 > ***************************************** > > > !DSPAM:45c4c2a781774554121338! -- 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
