commit 1cc3ed9c658d7f08bfa0f8efdc8ef54147cc2ab9
author Alexandr Miloslavskiy <alexandr.miloslavskiy@syntevo.com> Thu Jul 23 15:09:07 2020 +0200
committer Niraj Modi <niraj.modi@in.ibm.com> Tue Jul 28 03:56:17 2020 -0400
tree b0d5fd41c0a5e13a2ee2cc769280e76e3390699e
parent 5284661f3c0b3bade28ab33fbe4b6f6af8bdd9ef

Bug 565089 - [Win32] Table.selectAll quickly reverts back to previous selection

The problem happens when clicking a selected item in unfocused Table and
then doing something like Ctrl+A quickly to change Table's selection.

The problem was caused by early `SetFocus()` which occurred before
ListView was able to process the mouse event. This caused ListView to
think that the click occurred in a focused control, which changed the
way it's handled.

When a selected item is clicked in focused ListView, it starts a 500ms
timer (WM_TIMER with ID=42). The timer's purpose is to distinguish
between double-click and click-to-edit. When timer hits, it begins
inplace label editing (see `LVS_EDITLABELS`). For ListView without this
style (like in SWT), it merely resets selection to the item.

It seems that the problem that `SetFocus()` was solving is long gone.
Afterall, this code is there since the very first SWT commit! I tried
the following test:
1) Use SWT ControlExample, Table page
2) Click an item
3) Press keyboard arrow down, so that item gets input focus - it seems
   that Windows doesn't show focus until keyboard was used.
4) Click some other control
5) Click selected item in Table which is now not focused
6) Item shows input focus rectangle again.

This means that the desired behavior, as I understand it from code
comment, is working even without `SetFocus()`.

Even if I'm missing something, and focus rectangle will indeed be lost
sometimes, this is a very marginal feature compared to (1) the problem
of resetting selection and (2) having one more hack in SWT. Also, it's
closer to Windows behavior and there's no reason why SWT should have its
own logic unless this gives some value to users.

Change-Id: I626f2520eb5b5154b2b7b8d7825c228af1ef3945
Signed-off-by: Alexandr Miloslavskiy <alexandr.miloslavskiy@syntevo.com>