I've been meaning to post about binding CAPSLOCK to CTRL and vice versa in the keymapper, because the CAPSLOCK key behaves like a toggle even if it's bound to dosbox's CTRL. I tried this env variable solution, but it doesn't seem to change the behavior at all.

I'm using Star Control's KEYS.EXE to test this. It reports which keys it thinks are being held down. When I press down CTRL on my keyboard, it reports CAPSLOCK being held down. When I release the CTRL key, the CAPSLOCK indicator goes away.

However, when I press down CAPSLOCK on my keyboard, it reports CTRL is pressed down even after I release the CAPSLOCK key. The indicator goes away when I toggle CAPSLOCK on my keyboard again. Unless I'm misunderstanding Minuous's post, the environment variable should solve exactly this problem, but it doesn't.

@ripa:

Are you using the latest SDL.DLL? I can confirm that the solution I offered does work (with the latest SDL.DLL) BRICKS.EXE game under WinXP.
It shouldn't be necessary to do any remapping, so I don't know why you would want to map the Caps Lock key to the Ctrl key.

Thanks for this fix! I noticed similar problems with a few flight simulators; Airline Simulator/Airline Simulator 2, Airline Transport Pilot, as well as Flight Simulator 4.0.

AS/AS2 uses a SHIFT+CAPSLOCK combination to change views, and FS4 uses another combination (I forget offhand now, a combo with either NUMLOCK or SCROLLOCK) to do the same.

In AS2, I would hold down the SHIFT key and then press the CAPSLOCK key, and if I continued to hold down SHIFT (after releasing CAPSLOCK) the views would cycle wildly from one to the next. I found that if the CAPSLOCK light was on, I'd first have to press CAPSLOCK a single time to turn it off, and then quickly/briefly press the SHIFT+CAPSLOCK key combo to switch to the next view.

Previously, I couldn't quite put my finger on (or describe) what was happening... I just assumed it was a DOSBox sort of thing, but this fix works like a champ for it 😀

(edit) RE:FS4 - For Flight Simulator 4.0 it was the NUMLOCK key. A single press of the NUMLOCK would display the map, and a second press would hide the map. Previously, the function was sort of erratic; sometimes I couldn't get rid of the map, sometimes I couldn't get it to display.

With the above fix, it works fine 😀

Minuous wrote:

@ripa:

Are you using the latest SDL.DLL? I can confirm that the solution I offered does work (with the latest SDL.DLL) BRICKS.EXE game under WinXP.
It shouldn't be necessary to do any remapping, so I don't know why you would want to map the Caps Lock key to the Ctrl key.

I missed the part about having to download the new DLL file. With the file and the environment variable set, it works like expected (CAPSLOCK no longer behaves like a toggle in dosbox). Now I can swap CAPSLOCK with CTRL key in the dosbox mapper (I already do this in Windows using the scancode mapper in the registry, but it doesn't affect software that uses DirectInput).

It's much more comfortable when CTRL it's at CAPSLOCK's position. Thanks for posting this thread!

Minuous wrote:

A problem in SDL prior to version 1.2.14 was causing the behaviour of the LOCK key to not work as it should have. Instead of ret […]
Show full quote

A problem in SDL prior to version 1.2.14 was causing the behaviour of the LOCK key to not work as it should have. Instead of returning the up/down key status it was returning the toggled state and so caused problems with games that used it.
The current workaround is to issue the command:

set SDL_DISABLE_LOCK_KEYS=1

every time before launching DOSBox.
I don't know what version of SDL is included with DOSBox 0.74 but 1.2.14 is available from http://www.libsdl.org/release/SDL-1.2.14-win32.zip if the one included with 0.74 is obsolete.
Apparently the necessary setting of the SDL_DISABLE_LOCK_KEYS can be done internally by the emulator. Could that please be done for V0.75 so that the users don't have to stuff around with environment variables?

0..74 sets this variable if it is compiled against 1.2.14
however currently it compiled against 1.2.13 as we had some issues with 1.2.14
However more stuff should change internally by dosbox if 1.2.14 is detected related to keyboard handling.

Qbix wrote:

0..74 sets this variable if it is compiled against 1.2.14 however currently it compiled against 1.2.13 as we had some issues with 1.2.14

Would/are there be any (known) problems with using SDL v1.2.14 with the release version of DOSBox v0.74 (even though the release version was compiled against SDL v1.2.13)? I haven't noticed any with my bit of experimentation with it, but just wanted to make sure 😀

we had some problems when switching windows (and fullscreen and back)

Qbix wrote:

we had some problems when switching windows (and fullscreen and back)

Thanks for the info 😀 I'll keep that in mind when messing around with it. Currently the only games that I have a problem with are the ones that I mentioned before (AS/AS2/ATP/FS4; I'm assuming that AS97 as well as FS3 would have the same problem too).