I went ahead and downloaded the source tarball from the site. I
have been looking through the code, and I believe I have located the
source of the bug I have been describing. I suppose I could get a CVS
account and check this in or whatever but it seems like a lot of stuff to
go through just for this, and I figure it's easier to just point the bug out.
To wit:
-----from method HeaderInfoListImpl::Sort-----
-----in file src/mail/HeaderInfoImpl.cpp-----
long sortOrderOld = 0;
if ( m_reverseOrder )
{
// we do the reversal ourselves
sortOrderOld = m_sortParams.sortOrder;
m_sortParams.sortOrder &= ~1;
}
if ( m_mf->SortMessages(m_tableSort, m_sortParams) )
{
DUMP_TABLE(m_tableSort,
("after sorting with sort order %08lx",
m_sortParams.sortOrder));
}
else // sort failed
{
FreeSortData();
return false;
}
// BUGFIX: the offending line shoul;d be moved here
if ( m_reverseOrder )
{
// restore the real sort order so that comparing against it in
// SetSortOrder() has expected result when it is called later
// BUG: The next line restores the old (non-reversed sort order)
m_sortParams.sortOrder = sortOrderOld;
}
// BUG: This line will always set m_reversedTables to false
m_reversedTables =
IsSortCritReversed(m_sortParams.sortOrder);
// The above line should be moved to the BUGFIX location above
-----end of code-----
If you trace through the code you'll see the problem: regardless of
whether m_reverseOrder is true or false, the last line always sets
m_reversedTables to false. If the sort order is reversed, the code saves
the old (non-reversed) sort order, sorts the data in reverse, restores the
old sort order -- and then the last line notes whether the current sort
order is reversed. Of course, it never is, because the non-reversed sort
order has been restored already. The last line needs to be moved
ahead of the if-block so that it notes the reversal status of the reversed
sort. (This won't affect non-reversed sorts, since in that case the store-
reverse-restore mechanism will never be activated.)
Incidentally, there's also some code in another part of that file
which does a specific check to see whether the sort criteria makes use
of the sender address, which explains why this sorting bug does not
occur when sorting by sender.
--
--OKB
Brendan Barnwell
-------------------------------------------------------
This SF.net email is sponsored by: IBM Linux Tutorials.
Become an expert in LINUX or just sharpen your skills. Sign up for IBM's
Free Linux Tutorials. Learn everything from the bash shell to sys admin.
Click now! http://ads.osdn.com/?ad_id=1278&alloc_id=3371&op=click
_______________________________________________
Mahogany-Users mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/mahogany-users
