I'm using Windows 7 with Dexpot virtual window manager and DexGrid plugin and LOVE it! I had set ALT-CTRL-arrow to switch desktops (and ALT-CTRL-SHIFT-arrow to move active window and switch). This was working great for several months, but a few days ago, the switch desktops stopped working. When I went into Dexpot's (excellent) settings page to investigate, the key combination was still there, but had a little warning symbol next to it, implying Dexpot knew something's wrong, but didn't say what. What could've "stolen" that key combination?

I think to install Hotkey Explorer to solve this, but read some (old) iffy reviews about it. Are newer version more reliable? Alternately, would AutoHotKey give me this info? Another app?

note: the (?) in the question title means I'm not sure I stated this correctly: "Dexpot's system-wide hotkey". It also brings up many other completely unrelated questions containing "system-wide", so may throw others off. I'll be happy to edit the title if someone confirms or suggests a better description.

edit: I haven't installed any windows updates before the problem started (I thought there aren't any more since M$ stopped support, no?). Took me some tinkering to figure I installed a bunch of apps recently (more than I'd thought), but since I'm not sure when exactly the problem started, it's hard to pinpoint the guilty one this way :\. I thought I could "steal" it back with Dexpot, but no success. Does that mean an application can make "system-wide" hotkeys and "lock" them? Either way, I'd like to trace the hotkey associations, which should point me straight to the culprit.

Dexpot settings - Hotkeys

  • This is dexpot isn't it? You write dextop. Also installed any windows updates or other changes since this started happening? – LPChip Jun 12 '20 at 11:00
  • @LPChip: Oops, tnx :). Also edited to respond. – Neil Jun 13 '20 at 0:36

A hotkey registration works very simple in windows.

An app can make a hotkey claim if the hotkey is not yet claimed. They register and then it is send to their app until the app itself closes. As long as the hotkey is claimed, no other app can claim that hotkey. So if Dexpot starts before the other app starts, Dexpot gets the hotkey.

You have to figure out what app uses the hotkey. Close them one by one until Dexpot can get the hotkey again. Keep in mind, some services may claim the hotkey, so closing an app is not always all you need to do.

Once you figure out what app it is, see if you can reconfigure the shortcut keys in that app, or if there's nothing you can do, see if there is an alternative for that app that does not use that shortcut key.

  • This would work well when the hotkey is claimed by a GUI app, which can be easily opened and closed. As you mention, the hotkey may be claimed by a service, which makes things more difficult. The guilty service may have little or no resemblence to the name of the application I installed, hence be difficult to identify. On the other hand, stopping an incorrect service can have a catastrophic impact on the system AFAIK. So why bother? I only want to find the app associated with a hotkey. If I can also manage (ie un- and re-assign) the hotkeys from a centralized location, bonus! – Neil Jun 16 '20 at 20:13
  • There's no way for you to know what app is grabbing the hotkey other than pressing it, see what happens, and figure out what process just got a cpu spike. – LPChip Jun 16 '20 at 20:29
  • The thing is, I press the hotkey and nothing happens (as far as I can tell) :\. From what I read, Hotkey Explorer / Commander claims to tell. Does it not? – Neil Jun 20 '20 at 21:39

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.