After running the following prior to Windows 10 ...
Code:
Option Explicit
Private Sub Command1_Click()
Dim i%, J%
With Lv1
.View = lvwReport
.FullRowSelect = True
.MultiSelect = True
For i = 1 To 4
.ColumnHeaders.Add , , "Col " & i
.ColumnHeaders(i).Width = TextWidth("Col " & i) * 3
Next
For J = 1 To 50
.ListItems.Add , , "Row " & J
With .ListItems(.ListItems.Count)
For i = 2 To 4
.ListSubItems.Add , , "Col " & i
Next
End With
Next
End With
End Sub
... it was possible to select multiple adjacent rows by clicking and dragging (up or down) in the right hand side of the first column.
Under Windows 10 the smallest drag seems to select all rows imediatley and the mouse cursor jumps into the left bottom of the screen.
This is with the Listview from Common Controls v6 which I generally prefer to v5 because it allows the FullRowSelect option.
Rudimentary Tests using Listview v5 seem to indicate it has simiar problems.
Has anyone else noticed this? Does anyone have a solution?
Last edited by Magic Ink; Feb 5th, 2018 at 01:41 PM.
You'll have to ditch that creaky old MSCOMCTL.OCX sooner or later. It has too many warts.
The biggest wart is that it cannot make use of comctl32.dll, which is the only thing that gets updates to work properly with OSs after Windows NT 4.0/95/98.
This seems to be working fine here:
Not everything has a workaround though, so there are still rare occasions where you have to fall back on the limp MSCOMCTL.OCX control. It's a pity they chose to wrap it around a copy of the Common Control code instead of making use of comctl32.dll which would have saved us a lot of grief.
Thanks dil, however your demo malfunctions for me under Win 10 in exactly the same way as I described above for the v6 Listview. Under Win 7 with your demo I cannot extend the selection by dragging at all unless I begin the drag in Column 3.
Your
'Implement "FullRowSelect = True" equivalent:
code for the v5 Control is interesting and not something I was aware of before, thanks for that.
Last edited by Magic Ink; Feb 5th, 2018 at 02:32 PM.
Reason: added 'unless I begin the drag in column 3'
>You have to begin the drag after all columns.
But that is still not reliable for me in Win 10 and
I never had to do that prior to now using the v6 control and
doing that means the ListView has to be a bit wider than the sum of the widths of the 'used' columns.
I don't know if it is relevant but I noticed the same behavior on winrar (v 5.50). Out of habit, I tend to drag from bottom up to select files inside an opened .rar and as soon as I start dragging, the cursor jumps to the bottom right of the window! It only started happening recently and I suspect after the win 10 1709 update.
EDIT: I also tried the demo. On first try it's the same strange behavior (cursor jumps to edge of screen). If I firstly select a row, it then works as expected but only for the first "page" of visible rows. If I scroll to anywhere past the first page, the strange behavior is back!
Last edited by immortalx; Feb 5th, 2018 at 03:33 PM.
>You have to begin the drag after all columns.
But that is still not reliable for me in Win 10 and
I never had to do that prior to now using the v6 control and
doing that means the ListView has to be a bit wider than the sum of the widths of the 'used' columns.
This is how it works in XP and 7 too?
edit:Actually drag select works in XP intermittently...
I'm not convinced anything has changed, and even if it has I'm not sure what you can do but cope with it.
Here's another version, with the Explorer theme applied and fewer items added. Looks nicer, but you can still only "lasso from the bottom" if the ListView is tall enough to have empty space at the bottom.
It almost has to work this way or else you can't use drag and drop.
You'll have to ditch that creaky old MSCOMCTL.OCX sooner or later. It has too many warts.
The biggest wart is that it cannot make use of comctl32.dll, which is the only thing that gets updates to work properly with OSs after Windows NT 4.0/95/98.
This seems to be working fine here:
Not everything has a workaround though, so there are still rare occasions where you have to fall back on the limp MSCOMCTL.OCX control. It's a pity they chose to wrap it around a copy of the Common Control code instead of making use of comctl32.dll which would have saved us a lot of grief.
Wait what... I assure you there's nothing mscomctl can do that comctl32 can't unless you're excluding subclassing.
But anyway, the drag issue is common to modern listview; you have to drag from the 2nd column. If you don't need the themed translucent highlight, you can use 5.0 but not theme it with SetWindowTheme "explorer" then you can initiate a drag rectangle anywhere outside occupied label space, but not with full row select. Tradeoff.
But anyway, the drag issue is common to modern listview; you have to drag from the 2nd column. If you don't need the themed translucent highlight, you can use 5.0 but not theme it with SetWindowTheme "explorer" then you can initiate a drag rectangle anywhere outside occupied label space, but not with full row select. Tradeoff.
You can select the Explorer theme or not, but the key is FullRowSelect.
You can select the Explorer theme or not, but the key is FullRowSelect.
Sorry my previous comment wasn't phrased in the most clear way...
With a 5.0 ListView, you have two options regarding the selection rectangle:
1) Explorer theme, but have to start below or in a different column, both with and without FullRowSelect or
2) No Explorer theme, can start from main column anywhere after the caption ends, but not with FullRowSelect
Seems to me that all works well and reliably (in Win 10) if all rows are visible in the ListView, if they are not (i.e. we have to scroll to see some rows) then selection by dragging becomes unreliable using ListView v5 or v6.
Have you confirmed the problem persists using a non-themed v5? I just ask because the selection rectangle mechanics are so different. I'd also try setting the LVS_EX_DOUBLEBUFFER style on the v5 themed control.
That guy Tablacus says his mouse hook works and others are confirming; I'm pretty sure you can do that with just the v5 ListView, it's straightforward enough to port over. (Page 2 of the discussion you linked).
Edit: Even better, further down someone posted a similar method for VB6 directly.
Well you can always normal extended selection instead of the lasso approach:
Click the first item in the range, shift-click the end item in the desired range, control-click to select/de-select individual items. This is far more versatile anyway.
This all seems like much ado about nothing to me. Microsoft might change the behavior back or not depending on whether they consider it a bug or a feature.
LOL. It makes no sense to make single bugfixes. MS need to fix it. For my part I won't implement a workaround fix for my VBCCR ListView.. as this cannot be the solution for MS stupidity.
Dex, the other one might be easier... The fix from MSDN comments:
Originally Posted by Michiel123_708
Code:
Case WM_CAPTURECHANGED:
'THIS IS THE BUGFIX. THIS SOURCE HAS BEEN WRITTEN IN VB6, YOU JUST HAVE TO CONVERT IT TO C# or VB.NET yourself.
If m_IsWindows10 = 0 Then
'everything below Windows 10 does not have to do anything with the 'WM_CAPTURECHANGED' message
'just do default action, let Windows handle it
WindowProcLVObject = CallWindowProc(m_defWindowProcLVObject, hWnd, uMsg, wParam, lParam)
Else
''m_Windows10BugFixMouseDown' is a variable you set at the 'WM_LBUTTONDOWN' and 'WM_RBUTTONDOWN' message of this subclass to 1, and at the 'WM_LBUTTONUP' and 'WM_RBUTTONUP' to 0 again.
'This can be handy that if Windows is sending a 'WM_CAPTURECHANGED' to your listview, but you aren't selection anything (having mouse button down) at that moment that Windows does the default action. Just to avoid other side effects.
If m_Windows10BugFixMouseDown = 1 Then
Dim RC As RECT
RC.Left = 0
RC.Top = 0
RC.Right = 1
RC.Bottom = 1
'redraw api
RedrawWindow GetParent(lngOurLVHwnd), RC, ByVal 0&, RDW_NOERASE Or RDW_INVALIDATE
'WE MUST RETURN 0 IF WE PROCESS THIS MESSAGE
WindowProcLVObject = 0
Else
'just do default action, let Windows handle it
WindowProcLVObject = CallWindowProc(m_defWindowProcLVObject, hWnd, uMsg, wParam, lParam)
End If
End If
Have you confirmed the problem persists using a non-themed v5?
Did you get an answer to that question yet?
If "the problem" is a weird action such as lots of rows getting selected and the mouse pointer zooming off to somewhere like the lower-left corner of the current monitor.... then yes. Using the legacy DLL with the version 5.0 OCX does exhibit this behavior.
Using a manifest to load the Common Controls 6.x assembly cures that... if not exactly as some would want it to when you have FullRowSelect turned on.