On Wed, 17 Dec 2003 19:12:52 -0800 (Pacific Standard Time) BrenBarn <[EMAIL PROTECTED]> wrote:
B> I went ahead and downloaded the source tarball from the site. I B> have been looking through the code, and I believe I have located the B> source of the bug I have been describing. I'm very impressed -- to find the location of the bug so quickly in a huge codebase of unknown code is usually not easy. Thank you! B> If you trace through the code you'll see the problem: regardless of B> whether m_reverseOrder is true or false, the last line always sets B> m_reversedTables to false. If the sort order is reversed, the code saves B> the old (non-reversed) sort order, sorts the data in reverse, restores the B> old sort order -- and then the last line notes whether the current sort B> order is reversed. Of course, it never is, because the non-reversed sort B> order has been restored already. The last line needs to be moved B> ahead of the if-block so that it notes the reversal status of the reversed B> sort. (This won't affect non-reversed sorts, since in that case the store- B> reverse-restore mechanism will never be activated.) I don't really agree with your analysis of the problem but it doesn't really matter because the code was, indeed, buggy and I think I've fixed it now. Or rather I've definitely fixed it but I'm not sure if my fix is optimal speed-wise. In any case, thanks again for finding the bug! If you're curious, this is why I don't agree with the above: 1. m_reversedTables is not always false because the old sort order could be reversed by itself (it is not the same as m_reverseOrder) 2. if it were ever different from what it used to be, the code in the function just below would be able to set m_reverseOrder to true when threading is on which would break everything (it's not for nothing there are quite a few asserts checking that it is always off if we use threading) 3. so I think m_reversedTables is useless anyhow and I simply removed it because we simply can't reverse a threaded listing -- this would mean reversing the threads on screen and we definitely don't want this. So after my changes everything seems to work as expected, but at the cost of completely resorting the folder when sort order is reversed and threading is on. It would be nice (but not critical) to avoid this but I don't see how. Regards, VZ ------------------------------------------------------- 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
