Capital keys on widefs

Dylan · May 20, 2004

Hi,

I'm using FreeFD ND on client pc and sending keys trough widefs.

It all works fine with normal keys functions "v,n,i,ecc.." but not with capital ones "A,R,V,ecc..."

This is a part of my wideclient.ini:

.......

KeySend9=67,8,Run2 ( c keypress )

KeySend10=65,9,Run2 ( A kepress )

........

The problem is with the "A" kepress, because the ND get it as "a" and so it shows another function.

This happens for every capital key: it seems it's alwais non-capital, even if i wrote the "9" parameter in keysend lines and not "8".

Can anyone help me?

Thanks in advance

Pete Dowson · May 20, 2004

It all works fine with normal keys functions "v,n,i,ecc.." but not with capital ones "A,R,V,ecc..."

This is a part of my wideclient.ini:

.......

KeySend9=67,8,Run2 ( c keypress )

KeySend10=65,9,Run2 ( A kepress )

........

The problem is with the "A" kepress, because the ND get it as "a" and so it shows another function.

This happens for every capital key: it seems it's alwais non-capital, even if i wrote the "9" parameter in keysend lines and not "8".

Sorry, I don't know why that should be. The keys are passed on separately to Windows as 'shift' KeyDown, 'a' KeyDown, 'a' KeyUp, 'Shift' KeyUp". Such a sequence of messages through Windows also generates a "WM_CHAR" message which would derive the captital 'A'. There is no Windows keycode for capitals, only the separate operations for shift and so on.

Maybe it is the way the program is written, something to do with the way it is processing the messages. But I really can't see how it could get it wrong.

Can you try, temporarily, substituting, say, Notepad.exe for the program so you can see the characters actually being typed on screen?

Another idea would be to see if you can re-assign the key usage in the target program so that it doesn't need to differentiate between A and a in the first place. Or are the assignments fixed?

Finally, is the author still active? Maybe he could give some advice on this?

Regards,

Pete

Bob Church · May 21, 2004

Hi Pete,

I've had trouble with some sims when there was insufficient delay between the character changes. If the key changes didn't happen one change per

frame, the sim missed the modifier. It had to see:

Frame 1 - Shift Down

Frame 2 - "a" Down

Frame 3 - "a" Up

Frame 4 - Shift Up

If the shift and "a" went down or came up in the same frame, the sim missed the modifier. The release sequence mattered, too. It originally showed up when I started emulating HID keyboards for USB devices because I had the shift and the "a" in the same packet, I suspect the delay inherent in the PS2 keyboard transfers got around it in earlier times.

Best regards,

- Bob

The StickWorks

http://www.stickworks.com

Dylan · May 21, 2004

Hi Pete,

unlucky there is no possibility to reassign the keys in the software.

I tried using notepad.exe instead of the ND instrument as you suggested, but no keys are typed in notepad, normal or capital.

I don't know if it's a notepad problem for this.

I really don't know what to do now.

Maybe it's a delay about "shift" pressing as Bob said?

Waiting for news

Thanks again

Dylan

Pete Dowson · May 21, 2004

I tried using notepad.exe instead of the ND instrument as you suggested, but no keys are typed in notepad, normal or capital.

I don't know if it's a notepad problem for this.

You must have something wrong, then. I've run it with these parameters in the [user] section of WideClient.ini:

[user]

Run1=Notepad.exe

Close1=Yes

ActionKeys=Yes

KeySend1=65,8,Run1

KeySend2=65,9,Run1

This makes WideClient load up Notepad, just as it should be loading up your ND program.

The assigned KeySend1 button on FS then consistently types an 'a' in Notepad, and KeySend2 types an 'A'.

I've tested this with Windows XP and Windows 98SE. If your Notepad is not seing the keypresses you have something wrong for sure. Get that working first, then retry your ND.

Checking the keyboard message sequences produced using Microsoft's Spy++ program, I see:

001003B2 P WM_KEYDOWN nVirtKey:'A'

001003B2 P WM_CHAR chCharCode:'a' (97)

001003B2 P WM_KEYUP nVirtKey:'A'

for the lower case 'a', which is correct, and:

001003B2 P WM_KEYDOWN nVirtKey:VK_SHIFT

001003B2 P WM_KEYDOWN nVirtKey:'A'

001003B2 P WM_CHAR chCharCode:'A' (65)

001003B2 P WM_KEYUP nVirtKey:'A'

001003B2 P WM_KEYUP nVirtKey:VK_SHIFT

for the upper case. The order is always 100% consistent in these, and you'll note that Windows has correctly generated the CHAR messages with the 'a' ASCII code and 'A' ASCII codes, respectively.

Maybe it's a delay about "shift" pressing as Bob said?

I really don't know how that might happen. The message sequences being generated by WideClient are done by the Windows Journal Playback facilities. If you set "Log=DebugAll" in the INI file you'll get the messages saying what it is doing. For example, for my KeySend1 above I get:

(Note, this is probably more for Bob's benefit that yours. It is a bit technical).

4532 Action request for "Run1", KeySend0 - looking for Window<1:1>

4532Okay, found, sending 0 request <1:1>

4532 Setting hook for KeyHook action 1 <1:1>

4547 Hook set okay <1:1>

4547 Checked KeySend[5]=1, DoneOne=-1 <1:1>

4547 Actioncall for HC_GETNEXT<0:1>

4547 [wnd=140690, msg=256, paramL=0041, paramH=001E]done <0:1>

4547 Actioncall for HC_GETNEXT<0:0>

4547 [wnd=140690, msg=256, paramL=0041, paramH=001E]done <0:0>

4547 Actioncall for HC_SKIP<0:0>

4547done HC_SKIP <0:0>

4547 Actioncall for HC_GETNEXT<0:0>

4547 [wnd=140690, msg=257, paramL=0041, paramH=001E]done <0:0>

4547 Actioncall for HC_SKIP<0:0>

4547done HC_SKIP <0:0>

4547 Unhooking now <0:0>

The "HC_GETNEXT's are where Windows is asking for the next action. Message 256 is the "KEYDOWN", 257 is "KEYUP", and, in this case, the Key is hex 41 (65 decimal).

For the KeySend2 there are more steps:

16282 Action request for "Run1", KeySend1 - looking for Window<1:1>

16282Okay, found, sending 1 request <1:1>

16282 Setting hook for KeyHook action 2 <1:1>

16282 Hook set okay <1:1>

16282 Checked KeySend[6]=2, DoneOne=-1 <1:1>