http://bugs.winehq.org/show_bug.cgi?id=24514
Summary: LVM_SUBITEMHITTEST fails on Chinese and Japanese Versions of XP Product: Wine Version: 1.3.3 Platform: x86 OS/Version: Linux Status: UNCONFIRMED Severity: normal Priority: P2 Component: comctl32 AssignedTo: wine-bugs@winehq.org ReportedBy: austin.lund@gmail.com
In the test_hittest function for the listview test the following test fails for the Chinese and Japanese versions on the test bot:
/* subitem returned with -1 item too */ x = pos.x + 150; y = -10; test_lvm_subitemhittest(hwnd, x, y, -1, 1, LVHT_NOWHERE, FALSE, FALSE, FALSE);
The failures read:
listview.c:3056: Test failed: Expected -1 retval, got -2 listview.c:3056: Test failed: Expected -1 item, got -2 listview.c:3056: Test failed: Expected flags 0x1, got 0x4
This basically says that the message returned -2 (undocumented ?) and set the flags to LVHT_ONITEMLABEL.
Is y = -10 relative to the control client area or the parent window? How can you be on the item label in either case? Should the above values be added as successes to this test?
http://bugs.winehq.org/show_bug.cgi?id=24514
--- Comment #1 from Nikolay Sivov bunglehead@gmail.com 2010-09-25 16:49:53 CDT --- (In reply to comment #0)
In the test_hittest function for the listview test the following test fails for the Chinese and Japanese versions on the test bot:
/* subitem returned with -1 item too */ x = pos.x + 150; y = -10; test_lvm_subitemhittest(hwnd, x, y, -1, 1, LVHT_NOWHERE, FALSE, FALSE, FALSE);
The failures read:
listview.c:3056: Test failed: Expected -1 retval, got -2 listview.c:3056: Test failed: Expected -1 item, got -2 listview.c:3056: Test failed: Expected flags 0x1, got 0x4
This basically says that the message returned -2 (undocumented ?) and set the flags to LVHT_ONITEMLABEL.
Is y = -10 relative to the control client area or the parent window? How can you be on the item label in either case?
It's control area coordinate. Logically it can't be on label, but calculation code doesn't care, I imagine something like diving y coordinate by item height value.
Should the above values be added as successes to this test?
I don't think so. We need to make 'y' depend on item height (that depends on used font and styles).
P.S. I did some test with Control Spy - it's not an Asian system specific. You could see on it on any system I think. All you need is 'x' to be in subitem and small enough 'y' value. Let's say for (100, -200) in Control Spy example I get '-11' as a return value and same '-11' in a structure. So this is clearly undocumented behaviour, even documentation is broken.
http://bugs.winehq.org/show_bug.cgi?id=24514
Nikolay Sivov bunglehead@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- Severity|normal |minor
--- Comment #2 from Nikolay Sivov bunglehead@gmail.com 2010-09-26 02:42:26 CDT --- So if there's no application that depends on this for now, I'm suggesting it to be fixed in tests and another todo test to be added that shows negative subitem index increasing.
http://bugs.winehq.org/show_bug.cgi?id=24514
Nikolay Sivov bunglehead@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- Summary|LVM_SUBITEMHITTEST fails on |LVM_SUBITEMHITTEST should |Chinese and Japanese |return negative subitem |Versions of XP |index for negative Y | |coordinate
http://bugs.winehq.org/show_bug.cgi?id=24514
--- Comment #3 from Austin Lund austin.lund@gmail.com 2010-09-26 03:37:28 CDT --- (In reply to comment #2)
So if there's no application that depends on this for now, I'm suggesting it to be fixed in tests and another todo test to be added that shows negative subitem index increasing.
Setting y=-1 stops the failures, but I'm not exactly sure how to do the "negative subitem index increasing" bit to be locale independent as I'm not 100% sure what it's doing. It does seem to be doing a calculation of the index by just dividing the y coordinate by a height (perhaps the height of an item), but exactly where the change from -1 to -2 and -2 to -3 (etc.) occurs seems perplexing to me.
http://bugs.winehq.org/show_bug.cgi?id=24514
--- Comment #4 from Nikolay Sivov bunglehead@gmail.com 2010-09-26 03:45:43 CDT --- (In reply to comment #3)
(In reply to comment #2)
So if there's no application that depends on this for now, I'm suggesting it to be fixed in tests and another todo test to be added that shows negative subitem index increasing.
Setting y=-1 stops the failures, but I'm not exactly sure how to do the "negative subitem index increasing" bit to be locale independent as I'm not 100% sure what it's doing.
You need LVM_GETITEMRECT and then 'y = (top - bottom)/2' to be placed half item height outside list visible area.
It does seem to be doing a calculation of the index by just dividing the y coordinate by a height (perhaps the height of an item), but exactly where the change from -1 to -2 and -2 to -3 (etc.) occurs seems perplexing to me.
Same way, try 'y = 3*(top - bottom)/2' and expect -2 as index. Item rectangle fully depends on selected font, that's why it's better to avoid hardcoded values.
http://bugs.winehq.org/show_bug.cgi?id=24514
--- Comment #5 from Austin Lund austin.lund@gmail.com 2010-09-26 03:55:52 CDT --- (In reply to comment #4)
You need LVM_GETITEMRECT and then 'y = (top - bottom)/2' to be placed half item height outside list visible area.
I get the following from LVM_SUBITEMHITTEST:
-y coord return
37 to ?? 1 4 to 36 0 -13 to 3 -1 -30 to -14 -2 -31 to -47 -3 -48 to ?? -4
which has a difference of 16 except for zero which is double this. The vertical spacing from LVM_GETITEMSPACING is 17 (off by one?). LVM_GETITEMRECT does appear to have an overlap as for me in this case as item 1 has top 37 bottom 54, but item 0 has top 20 bottom 37. Perhaps LVM_GETITEMSPACING just subtracts these without taking the overlap into account.
I think this is enough to write a test.
http://bugs.winehq.org/show_bug.cgi?id=24514
--- Comment #6 from Nikolay Sivov bunglehead@gmail.com 2010-09-26 04:06:45 CDT --- (In reply to comment #5)
I get the following from LVM_SUBITEMHITTEST:
-y coord return
37 to ?? 1 4 to 36 0 -13 to 3 -1 -30 to -14 -2 -31 to -47 -3 -48 to ?? -4
which has a difference of 16 except for zero which is double this.
It's doubled cause you most likely have a header (could be switched off with LVS_NOCOLUMNHEADER).
The vertical spacing from LVM_GETITEMSPACING is 17 (off by one?). LVM_GETITEMRECT does appear to have an overlap as for me in this case as item 1 has top 37 bottom 54, but item 0 has top 20 bottom 37. Perhaps LVM_GETITEMSPACING just subtracts these without taking the overlap into account.
Probably yes, this deserves a separate test (correspondence of returned spacing and rectangle), could be affected by other styles too byt the way like grid for example.
I think this is enough to write a test.
Yes, please do. And feel free to ask if you get into some troubles with it.
http://bugs.winehq.org/show_bug.cgi?id=24514
--- Comment #7 from Austin Lund austin.lund@gmail.com 2010-10-03 21:34:32 CDT --- Created an attachment (id=31102) --> (http://bugs.winehq.org/attachment.cgi?id=31102) Tests for negative subitem index
I've written this patch and I'm trying to test it across the platforms on the testbot. I'm not sure if this is exactly what you were getting at or not. Seems to work for me.
http://bugs.winehq.org/show_bug.cgi?id=24514
--- Comment #8 from Austin Lund austin.lund@gmail.com 2010-10-05 19:54:30 CDT --- Patch committed 227b1fe2ca387f53895df7f5b1036dc8cff54835
http://bugs.winehq.org/show_bug.cgi?id=24514
--- Comment #9 from butraxz@gmail.com 2013-06-15 05:18:24 CDT --- This has not been updated for over 900 days.
Is this still an issue in 1.6-rc2 or higher or is this abandoned ?
https://bugs.winehq.org/show_bug.cgi?id=24514
--- Comment #10 from Austin English austinenglish@gmail.com --- (In reply to butraxz from comment #9)
This has not been updated for over 900 days.
Is this still an issue in 1.6-rc2 or higher or is this abandoned ?
Abandoned.
https://bugs.winehq.org/show_bug.cgi?id=24514
Austin English austinenglish@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- Status|UNCONFIRMED |RESOLVED Resolution|--- |ABANDONED
--- Comment #11 from Austin English austinenglish@gmail.com --- (In reply to Austin English from comment #10)
(In reply to butraxz from comment #9)
This has not been updated for over 900 days.
Is this still an issue in 1.6-rc2 or higher or is this abandoned ?
Abandoned.
Abandoned.
https://bugs.winehq.org/show_bug.cgi?id=24514
Austin English austinenglish@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- Status|RESOLVED |CLOSED
--- Comment #12 from Austin English austinenglish@gmail.com --- Closing.
https://bugs.winehq.org/show_bug.cgi?id=24514
Nikolay Sivov bunglehead@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- Status|CLOSED |REOPENED Resolution|ABANDONED |--- Ever confirmed|0 |1
--- Comment #13 from Nikolay Sivov bunglehead@gmail.com --- Tests are still todos, reopening.
https://bugs.winehq.org/show_bug.cgi?id=24514
Gijs Vermeulen gijsvrm@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- Status|REOPENED |NEW
--- Comment #14 from Gijs Vermeulen gijsvrm@gmail.com --- Tests are still todo in wine-6.7.
https://bugs.winehq.org/show_bug.cgi?id=24514
Gijs Vermeulen gijsvrm@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- Keywords| |testcase