#PB_ListView_MultiSelect causes screen readers to repeat list items when at the beginning/end

[Quin]

Steps to reproduce:
1. Start Narrator.
2. Run my below code and up/down arrow through the two lists. Notice the difference in behavior between the multiselect list and the single-select list when you're at the top/bottom of them.

Code: Select all

EnableExplicit

Define i.i
OpenWindow(0, #PB_Ignore, #PB_Ignore, 600, 400, "Test")
ListViewGadget(0, 5, 5, 250, 100)
ListViewGadget(1, 300, 5, 250, 100, #PB_ListView_MultiSelect)
For i = 0 To 10
AddGadgetItem(0, -1, "This is item number " + i)
AddGadgetItem(1, -1, "This is item number " + i)
Next
Repeat : Until WaitWindowEvent(1) = #PB_Event_CloseWindow

In my mind, the single-select list view is correct, as that's how listviews behave everywhere else in Windows, even lists that do let you select multiple items, e.g. explorer.

[Quin]

Just tested and can confirm that it also happens with #PB_ListView_ClickSelect

[Fred]

https://www.purebasic.fr/english/viewtopic.php?t=86350
I tried with NVDA on Windows 10 but I don't see any difference between the 2. I checked the ListIconGadget() gadget and we don't modify anything related to selection or keyboard handling, so that's wierd.

[Quin]

Perhaps its a bug in Windows? What if you create those lists in a pure Win32 C application and then try the same thing? Eliminate the possible layer of PB's gadgets, although I don't see any logical reason they'd be causing issues.

[Fred]

May be someone else can try to reproduce it, to ensure it's not related to a specific config

[breeze4me]

https://learn.microsoft.com/en-us/windo ... -selchange

For a multiple-selection list box, the LBN_SELCHANGE notification code is sent whenever the user presses an arrow key, even if the selection does not change.

In a multi-select listview gadget, holding down the arrow keys on the first and last item causes continuous LBN_SELCHANGE notifications, which seems to be causing the issue.
As you can see by running the code below, the same thing happens when the #PB_ListView_ClickSelect flag is set.

Code: Select all

Procedure WinCallback(hWnd, uMsg, WParam, LParam)
  If uMsg = #WM_COMMAND
    If (WParam >> 16) & $FFFF = #LBN_SELCHANGE
      If LParam = GadgetID(0)
        Debug "g0: " + GetGadgetState(0)
      ElseIf LParam = GadgetID(1)
        Debug "g1: " + GetGadgetState(1)
      EndIf
    EndIf
  EndIf
  ProcedureReturn #PB_ProcessPureBasicEvents
EndProcedure


Define i.i
OpenWindow(0, #PB_Ignore, #PB_Ignore, 600, 400, "Test")

SetWindowCallback(@WinCallback(), 0)

ListViewGadget(0, 5, 5, 250, 100)
ListViewGadget(1, 300, 5, 250, 100, #PB_ListView_MultiSelect)
;ListViewGadget(1, 300, 5, 250, 100, #PB_ListView_ClickSelect)
For i = 0 To 10
AddGadgetItem(0, -1, "This is item number " + i)
AddGadgetItem(1, -1, "This is item number " + i)
Next
Repeat : Until WaitWindowEvent(1) = #PB_Event_CloseWindow

[Quin]

Iiiiinteresting, so it's not a bug, just utterly baffling behhavior on the part of Microsoft. Who's surprised?
You're a wizard, Breeze4Me