Skip to main content

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
[nebula-dev] [compositetable] bug: changes in topRow == 0

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 <dietisheim@xxxxxxxxx>
Subject: Re: [nebula-dev][compositetable] bug: changes in topRow == 0
        get lost
To: Nebula Dev <nebula-dev@xxxxxxxxxxx>
Message-ID: <1170513875.5208.2.camel@pmobilead>
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
> nebula-dev@xxxxxxxxxxx
> https://dev.eclipse.org/mailman/listinfo/nebula-dev
>
>
> !DSPAM:45c30184308723936241041!
>



------------------------------

_______________________________________________
nebula-dev mailing list
nebula-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/nebula-dev


End of nebula-dev Digest, Vol 11, Issue 3
*****************************************

Back to the top