Open-shell-menu: Incompatiblity with PureText

[nmatt]

I use PureText with the default keyboard shortcut Win+V and experience the following incompatibility with Open Shell Menu.

The menu is activated by the following keyup/keydown sequence:

1. Win keydown
2. V keydown
3. Win keyup (=> activates menu)
4. V keyup

Either step 3 or 4 also triggers the PureText paste. In addition (and weirdly), the current window is minimized. (This happens with both the DEFAULT and the EXPERIMENTAL PureText paste mode.) The end result is that the window I've just been pasting in disappears and that the keyboard focus is on the opened Start menu.

The menu is not activated when steps 3 and 4 are reversed; however I very often inadvertently get the above sequence when pressing Win+V. I don't get this behavior under Windows 7 with the standard Start menu.

While PureText may be to blame as well, I would argue that the Start menu should not be triggered when there was a (non-modifier) keydown between the Win keyup and keydown.

This is with Open Shell 4.4.138 and PureText 6.2 under Windows 10 1903.

[Ibuprophen]

I've never personally heard of PureText...

Did you try to add/change the key combination within the Open Shell settings?

~Ibuprophen

[nmatt]

@Ibuprophen: I'm not sure what you mean. I'm using the Open Shell default settings where the Windows key opens the Open Shell menu.

[Ibuprophen]

I understand that part but, the software sometimes provides additional key combinations that may take over/override another one that was/is set.

I'm not stating that this is the exact culprit in question but, it may just be it. I may just install the software to see if I can duplicate this myself.

Is this a free or paid software and where is the Official source in obtaining it?

~Ibuprophen

[nmatt]

PureText is free (see the page I linked), but not open source as far as I can tell. I emailed the author with reference to this GitHub issue, maybe he will chime in.

I should also note that (1) I have Clipboard history turned off (Settings > System > Clipboard) and (2) I have the repeat delay set to the shortest value and the repeat rate to the fastest value in the Keyboard Properties (run "main.cpl @1"), which may conceivably be a factor in reproducing the issue.

[SteveMil]

I'm the author of PureText. Sorry for the lag - been on vacation.

In this case, you can probably give the blame to PureText. It's not so much of a bug, but rather just how PureText works. The default hotkey in PureText is WIN+V, but it allows you to pick a different hotkey. I would recommend changing either it or the one in Open Shell Menu.

Some technical details on what is happening...

PureText tries to use RegisterHotKey(), but that rarely works these days since just about everything is already registered and Windows is very greedy about the WINDOWS key. PureText will most likely end up using SetWindowsHookEx(WH_KEYBOARD_LL) and do manual detection of the hotkey.

The real problem is with how PureText performs the paste operation. It does this by faking a CTRL+V being pressed, and it is trying to do this while you are currently holding WIN+V at the same time. This has all worked flawlessly for over 15 years, but the last couple releases of Windows 10 have broke/changed things a bit and then Windows added the new cloud clipboard to make it even worse.

WIN+V+CTRL+V used to actually perform a paste just fine, so all PureText had to do is fake a CTRL+V while you were still holding (or even released) your WIN+V hotkey. That no longer works, so PureText either has to wait for you to release WIN+V completely or has to fake a WINDOWS up event before faking the CTRL+V and then possibly has to fake a WINDOWS down event after it to keep your keyboard state intact.

It has become a bit delicate, but works the majority of the time. I'm not all that surprised that things break if another app is also trying to consume the same hotkey and perform an action. I wish I could just do away with WIN+V, but it's the key all my users have trained themselves to use for many years.

[coddec]

I'm the author of PureText. Sorry for the lag - been on vacation.

In this case, you can probably give the blame to PureText. It's not so much of a bug, but rather just how PureText works. The default hotkey in PureText is WIN+V, but it allows you to pick a different hotkey. I would recommend changing either it or the one in Open Shell Menu.

Some technical details on what is happening...

PureText tries to use RegisterHotKey(), but that rarely works these days since just about everything is already registered and Windows is very greedy about the WINDOWS key. PureText will most likely end up using SetWindowsHookEx(WH_KEYBOARD_LL) and do manual detection of the hotkey.

The real problem is with how PureText performs the paste operation. It does this by faking a CTRL+V being pressed, and it is trying to do this while you are currently holding WIN+V at the same time. This has all worked flawlessly for over 15 years, but the last couple releases of Windows 10 have broke/changed things a bit and then Windows added the new cloud clipboard to make it even worse.

WIN+V+CTRL+V used to actually perform a paste just fine, so all PureText had to do is fake a CTRL+V while you were still holding (or even released) your WIN+V hotkey. That no longer works, so PureText either has to wait for you to release WIN+V completely or has to fake a WINDOWS up event before faking the CTRL+V and then possibly has to fake a WINDOWS down event after it to keep your keyboard state intact.

It has become a bit delicate, but works the majority of the time. I'm not all that surprised that things break if another app is also trying to consume the same hotkey and perform an action. I wish I could just do away with WIN+V, but it's the key all my users have trained themselves to use for many years.

Will this https://www.autohotkey.com/ help some how?
If not, just forget abou it 😉

[nmatt]

Hi Steve, thanks for the explanations!

Just to be clear, when you say:

WIN+V+CTRL+V used to actually perform a paste just fine, so all PureText had to do is fake a CTRL+V while you were still holding (or even released) your WIN+V hotkey. That no longer works, so PureText either has to wait for you to release WIN+V completely or has to fake a WINDOWS up event before faking the CTRL+V and then possibly has to fake a WINDOWS down event after it to keep your keyboard state intact.

Does that mean PureText does any of the latter two, and if so, which one? Or does it still just add CTRL+V while WIN+V is being pressed?