Wt

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

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.

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 ?

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).

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.