PCem

Sorry if this has been discussed before, but have there ever been any attempts to look into trapping ALT+TAB? As things stand, it's getting sent to both the guest and the host, in fullscreen as well as windowed mode. This, of course, makes it basically impossible to use ALT+TAB on the emulated system, which is often a major workflow killer. How have people been dealing with this? Is there some workaround I'm missing? And, can anyone summarize why things have been set up this way and what technically stands in the way of fixing it? If it's just a matter of wanting to retain the ability to ALT+TAB away from PCem itself, surely that's something that calls for a toggle in PCem's settings that people can use as befits their needs (i.e., a "trap ALT+TAB" checkbox or similar). As all of the other standard system keys and key combinations (CTRL+SHIFT+ESC, Win key, etc.) are trapped as one would expect, with the sole obvious exception of CTRL+ALT+DEL, I wouldn't expect there to be any fundamental limitations here.

Just a quick note: under Linux, alt+tab already works fine.

This was trapped in v12 and earlier, but got broken in the GUI rework in v13. I've just spent a couple of hours trying to get it working again, without success - it looks like wxWidgets is interfering with PCem's keyboard hook somehow, preventing ALT-TAB or any other relevant messages reaching it.

Hmm, that's unfortunate. Thanks for looking into it, Sarah. I know we've got some wxWidgets gurus here, hopefully someone has a clue what can be done about this under Windows... anyone?

My memory is a bit vague, but I think I remember discussions about input being handled by SDL2. Maybe try looking there?

I am looking at the code, and currently, the place where the keyboard handling is done is in two files, different depending on the platform:

windows: wx-sdl2-display-win.c
linux/osx: wx-sdl2-display.c

I see that the file is quite similar, but with several differences. They were forked at revision 821. After that, there hasn't been much changes. (Note @Sarah: I see that revision 840 added a change related to the mouse in the win file that wasn't ported back to the non-win file)

One relevant difference I see is how they are interacting with the keyboard. on the linux one, it uses SDL_KEYDOWN, SDL_KEYUP, while on windows, it uses directly WM_INPUT. And there are also some other keyboard hooks and hints (on the windows one).

I haven't looked further nor tried anything else, and while i've done some coding about keyboard handling on windows, it generally has been with the Windows API, not with the SDL API, so anyone is still welcome to investigate it further.