DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUGĀ·
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
<http://issues.apache.org/bugzilla/show_bug.cgi?id=43068>.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED ANDĀ·
INSERTED IN THE BUG DATABASE.

http://issues.apache.org/bugzilla/show_bug.cgi?id=43068


[EMAIL PROTECTED] changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
  Attachment #20619|0                           |1
        is obsolete|                            |




------- Additional Comments From [EMAIL PROTECTED]  2007-08-13 02:26 -------
Created an attachment (id=20654)
 --> (http://issues.apache.org/bugzilla/attachment.cgi?id=20654&action=view)
Improving the line selection fix

I reviewed this fix again and made some adjustments. Previous patch had a bug
when the user completely removes the filter after applying a filter (This mean
the filter text == "" situation). It was not selecting the event which was
selected with the filter on. I have fixed it in this patch.
I checked the fix with the generators in the tutorial. But it generates events
continuously and even if we select a particular event, it selects the last
event as new events come in. Because of that, we can't see the results even if
the fix works fine. So to check the fix I think we have to stop the generator
for a while and select a particular event and then play with it by applying
different filters. When I checked it that way, the fix works fine and it
maintains the selected line. I didn't come to a situation where it selects
multiple lines.
Actually the bug was due to only remembering the index in the table between
filters. So if the selected line is the index 5 in the table, it was
maintaining this index even if the filters are applied. As this index is not
related to the events, different event IDs was fitting to that index in the
table. That's why it was selecting rows without any relevance. In my fix I have
remembered the event ID of the selected event and that ID is selected after the
filter, if that ID is in the filtered result. If not the last event is
selected.
So that behavior of coming to the previously selected event even after 2 or 3
filters was due to above mentioned behavior and now it is fixed. I had missed
the scenario of coming back to the empty filter situation after a filter, in
the previous patch and it is fixed in this new patch.
Check it again and please comment if it doesn't behave as expected or if there
are more modifications to be done.


-- 
Configure bugmail: http://issues.apache.org/bugzilla/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug, or are watching the assignee.

---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Reply via email to