Bug #121
closedWStandardItemCompare if WT_TARGET_JAVA isn't defined causes assert
0%
Description
Do:
- Create a WTreeView and associate a WStandardItemModel.
- Add WStandardItem instances of the same WString.
- Click the column sorting icon twice.
See:
- You get an assert in _Debug_lt_pred (xutility).
Remark:
- If both item1 and item2 exist in WStandardItemCompare and WT_TARGET_JAVA isn't defined the result is either --1 or 1.
- On the other hand the compare function in WAbstractItemModel.c returns 0 if the two 'cells' are equal.
- Since WStandardItemCompare only calls the < operator (and not the ==), it loses precision because it considers 'item1 < item2' to be 1 and 'item2 < item1' also to be 1. The result however should be 0 since they are equal.
Updated by Koen Deforche about 14 years ago
- Status changed from New to InProgress
- Assignee set to Koen Deforche
Updated by Koen Deforche about 14 years ago
Hey Randy,
With what version of Wt are you seeing this problem? I vageuly remember having fixed this some time ago, but am unsure.
Regards,
koen
Updated by Randy Voet about 14 years ago
wt-2.99.5. I just now used git to clone the public repository and WStandardItem.c line 43 still states: "result = (*item1) < (*item2) ? --1 : 1;". The Java version on the other hand calls WStandardItem::compare, but that function is private and I see no friend class definition for WStandardItemCompare.
Updated by Koen Deforche about 14 years ago
Randy Voet wrote:
wt-2.99.5. I just now used git to clone the public repository and WStandardItem.c line 43 still states: "result = (*item1) < (*item2) ? --1 : 1;". The Java version on the other hand calls WStandardItem::compare, but that function is private and I see no friend class definition for WStandardItemCompare.
That is true, but, bool operator()(int r1, int r2), which should implement "<", uses ::compare() only to decide whether a row is less than b, and therefore only differentiates values returned from compare() as either --1 or not. Thus it does not matter that compare wrongly returns 1 instead of 0 since ::compare() is only used from within the operator() method.
I seem to recall that this issue used to exist but got solved. So, I would appreciate whether you can confirm that you have the bug still with the current version, or, if not, perhaps send me the small test case that reproduces the problem ?
Updated by Randy Voet about 14 years ago
I'll try the development snapshot next week, but basically I think the problem happens because if 'order' is 'DescendingOrder' the sign of result is inverted. So a result of 1 becomes --1 (which is < 0), while 0 remains 0 (so not < 0).
My use case is simple (but again, I'll provide one next week if it still happens with the development snapshot):
- It's a single WTreeView that has an associated WStandardItemModel.
- The WStandardItemModel has a couple of std::string WStandardItems.
- Clicking on the sorting header twice causes an assert in _Debug_lt_pred (where std::sort checks that if 'a < b' then at least 'b < a' isn't true also).
Updated by Koen Deforche about 14 years ago
I think I get it now. The current implementation was confusing anyway (trying to mix the Java and C comparison logic too much).
I have fixed it by splitting out Java and C again, I'll push this to public git by the end of the day.
Thanks for your patience.
Updated by Koen Deforche about 14 years ago
- Status changed from InProgress to Closed