SOLVED! Virtual listview; validity of "Item" in "Edited" when Selection changed

[d7_2_laz]

Yes, and so no surprise that it had been so hard to find a way out the the issue we did speak about. Because within CNNotify we didn't have yet the relevant (click-)information available here, whereas the variables involved appeared to be infected by subsequent cursor positions instead.

Not at all an easy situation for Lazarus resp. LCL to deal with. But i feel it gets more stabilzed step by step, so i'm optimistic.

Btw about the recent patches: no news are good news here .. it's still working fine!

Hopefully we don't need next time an user accessible ClickedIdx for a different scenario. So i agree with the encapsulation but have a bit mixed feeling though.

[wp]

Committed the new version (https://gitlab.com/freepascal.org/lazarus/lazarus/-/commit/c0c30424debbd95c58fc9e8b98293dba55292d12); I can always revert it if something very severe appears.

What is left for me is the annoying issue in virtual mode that selection jumps to the first item when a non-special key is pressed incidentally (https://gitlab.com/freepascal.org/lazarus/lazarus/-/issues/39715). One possible work-around could be to kill all non-special key presses in the ListView's KeyDown method.

Code: Text  [Select][+][-]

1. procedure TCustomListView.KeyDown(var Key: Word; Shift: TShiftState);
2. const
3.   ALLOWED_VIRTUALMODE_KEYS = [VK_F2, VK_LEFT, VK_RIGHT, VK_UP, VK_DOWN,
4.     VK_HOME, VK_END, VK_PRIOR, VK_NEXT, VK_INSERT, VK_DELETE, VK_ESCAPE];
5. begin
6.   if OwnerData and not (Key in ALLOWED_VIRTUALMODE_KEYS) then
7.     Key := 0;
8.  
9.   if not ReadOnly and (Key = VK_F2) and (Shift = []) then
10.   begin
11.     ShowEditor;
12.     Key := 0;
13.   end else
14.     inherited KeyDown(Key, Shift);
15. end;

I don't like it, though, because this is a Windows-only issue and therefore should be fixed in the win32 widgetset.

[EDIT]
Here's a more widgetset-conformal solution. In lcl/interfaces/win32/win32wscustomlistview.inc, add to function ListViewProc (of course, do not modify procedure TCustomListView.KeyDown):

Code: Pascal  [Select][+][-]

1. function ListViewProc(...);
2. begin
3.   case Msg of
4.     ...
5.     WM_CHAR:
6.       begin
7.         // Prevent jumping to first item when a key is pressed in virtual mode
8.         // Issue #39715
9.         WindowInfo := GetWin32WindowInfo(Window);
10.         ListView := TListView(WindowInfo^.WinControl);
11.         if ListView.OwnerData then
12.         begin
13.           Result := 0;
14.           exit;
15.         end;
16.       end;
17.   ...

[d7_2_laz]

That's interesting, i also had tried that Key:= 0, limited by conditions, too but didn't like it either
(but mostly because with this reactice correction the positive reason-why would be still unidentified.
 But i had no idea yet where to search in the hierarchy. Presumingly item- resp. selected- index is set or preinitialized with zero somewhere)
 
 I tried the widgetset change and it does suppress the jump-to-beginning, but i don't understand yet how it works regarding the conditions
 (in combination with Shift, Ctrl, ..  a char is allowed).
 Currently i encounter the following caveat:
 - "builtin"-keystrokes resp. common combination like Ctrl-a, Ctrl-x .... do still work
 - user defined keystrokes like eg. Ctrl-s  are broken (i mean, if i define on app level that when pressing Ctrl and  "s" on an item, something specific should be done, it won't work now)
I'm a bit unsure about this difference. Shouldn't all combinations with Shift, Ctrl, .. and char passed through?

[d7_2_laz]

As there apparently a special rule might only concern the control key (to be verified), maybe something like this, for to alloe Ctrl  + 'char' ?

Code: Pascal  [Select][+][-]

1.     WM_CHAR:
2.       ......
3.         if ListView.OwnerData then
4.           if (GetKeyState(VK_CONTROL) >-1) then
5.           begin
6.             Result := 0;
7.             exit;
8.           end;

[wp]

Yes, seems to be better, at least.

BTW, the state of the CTRL key can be extracted from the lparam of the message: https://docs.microsoft.com/en-us/windows/win32/inputdev/wm-char