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]
