Project

General

Profile

Bug #121

WStandardItemCompare if WT_TARGET_JAVA isn't defined causes assert

Added by Randy Voet almost 13 years ago. Updated almost 13 years ago.

Status:
Closed
Priority:
Normal
Assignee:
Target version:
-
Start date:
10/13/2009
Due date:
% Done:

0%

Estimated time:

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.
#1

Updated by Koen Deforche almost 13 years ago

  • Status changed from New to InProgress
  • Assignee set to Koen Deforche
#2

Updated by Koen Deforche almost 13 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

#3

Updated by Randy Voet almost 13 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.

#4

Updated by Koen Deforche almost 13 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 ?

#5

Updated by Randy Voet almost 13 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).
#6

Updated by Koen Deforche almost 13 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.

#7

Updated by Koen Deforche almost 13 years ago

  • Status changed from InProgress to Closed

Also available in: Atom PDF