[1318] Can't type certain characters in the string editor

[MarioBrosCom]

This isn't a new bug to build 1318, but it doesn't seem to have gotten any attention (or maybe I'm the only one experiencing it).

The [, ], ', \, and ` keys are all incorrectly mapped in the String editor. Pressing the `, [, or ' keys produces nothing, pressing ] makes a [, and pressing \ makes a ]. The \ key in particular is crucial for entering string control codes.

The String editor has been partially broken since at least a couple hundred builds back for me. I'm running it on Windows 7 x64, but it wasn't working on Vista x64 either.

I'm not sure this is reproducible if it's only affecting me.

[XMuppetSB]

The backslash can be displayed if you type this: \91.
By the way, I too am running ZQuest on Windows 7 64 Bit, but I'm not seeing any of the problems you're seeing with the rest of the characters you mentioned.

[MarioBrosCom]

I was worried about that.

By not being able to type in \, I mean it doesn't even show in the editor. Instead, I get ] if I try to type a \. I can't use string control codes or escape sequences at all.

[Nicholas Steel]

Are you using a program that reconfigures the layout of your keyboard? Try setting your Keyboard layout to US 101.

[MarioBrosCom]

I've already tried various keyboard settings with no success (US layout is my default, but I tried the Canadian bilingual layouts as well just in case).

[Shoelace]

http://armageddongames.net/showthread.php?45506-Keyboard-Bug
^In that thread, I have the same problem. It sucks because I need to do string edit the Hero of Dreams, but I need to wait for I get an external keyboard because of the bug. >_<

[Saffith]

I don't know if I can fix this, but I've got to try, at least... Would you guys do something for me?
Download this: http://www.mediafire.com/?oxpga90rcd4gw8t
It's an alternate alleg42.dll with some logging in the key reading functions. Put it in your ZC directory, start up ZQuest, and press this sequence of keys (ignore the spaces):

1 2 3 [ ] \ / ' ` 4 5 6

Don't press any other keys; if any dialogs come up, close them with the mouse before continuing. Afterward, there should be some lines in allegro.log referring to ureadkey(). Post those.

[Shoelace]

Hopefully I did this right: All I did was open Zquest the newest version and pressed the keys after closing the first boxes that always come up, and looked in the log, and this is what I have:

ureadkey() start; scancode: 0
ureadkey() end 3; c: 49, scancode: 28
ureadkey() start; scancode: 0
ureadkey() end 3; c: 50, scancode: 29
ureadkey() start; scancode: 0
ureadkey() end 3; c: 51, scancode: 30
ureadkey() start; scancode: 0
ureadkey() end 3; c: 0, scancode: 99
ureadkey() start; scancode: 0
ureadkey() end 3; c: 91, scancode: 65
ureadkey() start; scancode: 0
ureadkey() end 3; c: 93, scancode: 66
ureadkey() start; scancode: 0
ureadkey() end 3; c: 47, scancode: 74
ureadkey() start; scancode: 0
ureadkey() end 3; c: 0, scancode: 101
ureadkey() start; scancode: 0
ureadkey() end 3; c: 0, scancode: 102
ureadkey() start; scancode: 0
ureadkey() end 3; c: 0, scancode: 102
ureadkey() start; scancode: 0
ureadkey() end 3; c: 0, scancode: 102
ureadkey() start; scancode: 0
ureadkey() end 3; c: 0, scancode: 102
ureadkey() start; scancode: 0
ureadkey() end 3; c: 0, scancode: 102
ureadkey() start; scancode: 0
ureadkey() end 3; c: 0, scancode: 102
ureadkey() start; scancode: 0
ureadkey() end 3; c: 0, scancode: 102
ureadkey() start; scancode: 0
ureadkey() end 3; c: 0, scancode: 102
ureadkey() start; scancode: 0
ureadkey() end 3; c: 0, scancode: 102
ureadkey() start; scancode: 0
ureadkey() end 3; c: 0, scancode: 102
ureadkey() start; scancode: 0
ureadkey() end 3; c: 0, scancode: 102
ureadkey() start; scancode: 0
ureadkey() end 3; c: 52, scancode: 31
ureadkey() start; scancode: 0
ureadkey() end 3; c: 53, scancode: 32
ureadkey() start; scancode: 0
ureadkey() end 3; c: 54, scancode: 33

[Saffith]

That's what I was after, though it may not be necessary after all. Turns out Allegro can handle different keyboard layouts, but it doesn't pay any attention to the system setting. Hardly surprising.
I haven't actually gotten it to do anything different yet, but I'm working on it...

[Saffith]

I never asked, have you tried using a software keyboard? In Windows 7, I think it should be under Accessories -> Ease of Access.

Turns out that Allegro keyboard stuff I was looking at doesn't apply to Windows, so... I don't know. I'm not optimistic at this point.

[MarioBrosCom]

I didn't see this until today.

There's no difference between using the on-screen keyboard and the physical one.

I'm using an HP laptop too, so maybe that has something to do with the problem.

[Saffith]

Try this: http://www.mediafire.com/?jm88oub1rw1bv3k
It definitely won't work normally, but see if those keys are still wrong in the string editor.

[MarioBrosCom]

Sorry, still no luck with that. I tried it with both the physical and on-screen keyboard and the results were the same (except now, the preview box doesn't update automatically either).

[Colossal]

This may be known by now, but the ZScript editor is also affected and pressing = also does nothing. This is on a Windows 7 desktop and this didn't happen with my old Windows 2000 desktop, if that helps at all.

[Saffith]

Huh. Has anyone had this problem on a version of Windows other than 7? Anyone tried two different versions on the same computer?

Here's another idea: go to allegro.cc and download another game or two (with source code available, preferably) and see if you have the same problem.

[Gleeok]

You can't go wrong with something like White Butterfly (http://www.allegro.cc/depot/WhiteButterfly). :)


edit: can't remember if you can remap the keys though...

[Colossal]

Here's one that supports remapping keys: Purple Martians. (http://www.allegro.cc/depot/PurpleMartians/)

I get weird results with the keys in question: [ is detected as "AT", ] is detected as "OPENBRACE", \ is detected as "CLOSEBRACE", = is detected as "CIRCUMFLEX", etc. The openbrace and closebrace are consistent with ZC and I'm not sure what to make of the other key names.

EDIT: ` is "KANJI", ' is "COLON2" (; is "COLON", but that key was working properly). Well, at least the key presses are detected.

[Shoelace]

Huh. Has anyone had this problem on a version of Windows other than 7? Anyone tried two different versions on the same computer?

Yeah, only on Windows 7. And it happens on all versions, including 2.10, 1.92, etc.

[MarioBrosCom]

Huh. Has anyone had this problem on a version of Windows other than 7? Anyone tried two different versions on the same computer?

Here's another idea: go to allegro.cc and download another game or two (with source code available, preferably) and see if you have the same problem.

I recall having this problem back when I was still using Vista, as well. I had no problems with the keyboard on my old XP machine.

I've found a partial workaround for typing ' and " using the Canadian French keyboard layout: Shift+2 (ie @) makes " and Shift+, (ie <) makes '.

There are still mapping issues with the exact six keys I mentioned before (\, ], [, ', `, and =) -- none produce any output using the Canadian French layout.

For convenience, here's what each English key gets mapped to in the French layout:


EN: {[ }] |\ '" `~ +=
FR: ^^ ¨¸ >< `` |# +=

Edit: Maybe the bug is similar to this one: http://www.allegro.cc/forums/thread/582398 ?

[Shoelace]

I just brought an external keyboard so I can work on the strings on my game.... but sadly, it did not fix the issue. So basically it happens on external keyboards too. :(

[Gleeok]

Are all the mappings consistent with all windows 7 users, or just some, or, only 64bit? Anyone have a look in wkeybd.c yet?

http://alleg.svn.sourceforge.net/viewvc/alleg/allegro/branches/4.2/src/win/wkeybd.c?revision=12635&view=markup


edit: ..Actually, chances are anyone on win7 getting this bug is going to have to manually replace the alleg.dll once this gets fixed.

[MarioBrosCom]

I'm not sure which hex values correspond to which keys on my keyboard, but it looks like the problem keys are 0x0D (KEY_EQUALS), 0x1A (KEY_OPENBRACE), 0x1B (KEY_CLOSEBRACE), 0x28 (KEY_QUOTE), 0x29 (KEY_TILDE), and 0x2B (KEY_BACKSLASH). My laptop keyboard also has a second backslash/pipe key which I assume is 0x56(KEY_BACKSLASH2). It's hard to be tell if these are correct, since both my laptop keyboard and Microsoft Arc keyboard have compact keyboard layouts.

[Gleeok]

It looks like they are mapped correctly in allegro, so that's not it....




/************************************************** **************************
*
* DirectInput keyboard scan codes
*
************************************************** **************************/
#define DIK_ESCAPE 0x01
#define DIK_1 0x02
#define DIK_2 0x03
#define DIK_3 0x04
#define DIK_4 0x05
#define DIK_5 0x06
#define DIK_6 0x07
#define DIK_7 0x08
#define DIK_8 0x09
#define DIK_9 0x0A
#define DIK_0 0x0B
#define DIK_MINUS 0x0C /* - on main keyboard */
#define DIK_EQUALS 0x0D
#define DIK_BACK 0x0E /* backspace */
#define DIK_TAB 0x0F
#define DIK_Q 0x10
#define DIK_W 0x11
#define DIK_E 0x12
#define DIK_R 0x13
#define DIK_T 0x14
#define DIK_Y 0x15
#define DIK_U 0x16
#define DIK_I 0x17
#define DIK_O 0x18
#define DIK_P 0x19
#define DIK_LBRACKET 0x1A
#define DIK_RBRACKET 0x1B
#define DIK_RETURN 0x1C /* Enter on main keyboard */
#define DIK_LCONTROL 0x1D
#define DIK_A 0x1E
#define DIK_S 0x1F
#define DIK_D 0x20
#define DIK_F 0x21
#define DIK_G 0x22
#define DIK_H 0x23
#define DIK_J 0x24
#define DIK_K 0x25
#define DIK_L 0x26
#define DIK_SEMICOLON 0x27
#define DIK_APOSTROPHE 0x28
#define DIK_GRAVE 0x29 /* accent grave */
#define DIK_LSHIFT 0x2A
#define DIK_BACKSLASH 0x2B
#define DIK_Z 0x2C
#define DIK_X 0x2D
#define DIK_C 0x2E
#define DIK_V 0x2F
#define DIK_B 0x30
#define DIK_N 0x31
#define DIK_M 0x32
#define DIK_COMMA 0x33
#define DIK_PERIOD 0x34 /* . on main keyboard */
#define DIK_SLASH 0x35 /* / on main keyboard */
#define DIK_RSHIFT 0x36
#define DIK_MULTIPLY 0x37 /* * on numeric keypad */
#define DIK_LMENU 0x38 /* left Alt */
#define DIK_SPACE 0x39
#define DIK_CAPITAL 0x3A
#define DIK_F1 0x3B
#define DIK_F2 0x3C
#define DIK_F3 0x3D
#define DIK_F4 0x3E
#define DIK_F5 0x3F
#define DIK_F6 0x40
#define DIK_F7 0x41
#define DIK_F8 0x42
#define DIK_F9 0x43
#define DIK_F10 0x44
#define DIK_NUMLOCK 0x45
#define DIK_SCROLL 0x46 /* Scroll Lock */
#define DIK_NUMPAD7 0x47
#define DIK_NUMPAD8 0x48
#define DIK_NUMPAD9 0x49
#define DIK_SUBTRACT 0x4A /* - on numeric keypad */
#define DIK_NUMPAD4 0x4B
#define DIK_NUMPAD5 0x4C
#define DIK_NUMPAD6 0x4D
#define DIK_ADD 0x4E /* + on numeric keypad */
#define DIK_NUMPAD1 0x4F
#define DIK_NUMPAD2 0x50
#define DIK_NUMPAD3 0x51
#define DIK_NUMPAD0 0x52
#define DIK_DECIMAL 0x53 /* . on numeric keypad */
#define DIK_OEM_102 0x56 /* < > | on UK/Germany keyboards */
#define DIK_F11 0x57
#define DIK_F12 0x58
#define DIK_F13 0x64 /* (NEC PC98) */
#define DIK_F14 0x65 /* (NEC PC98) */
#define DIK_F15 0x66 /* (NEC PC98) */
#define DIK_KANA 0x70 /* (Japanese keyboard) */
#define DIK_ABNT_C1 0x73 /* / ? on Portugese (Brazilian) keyboards */
#define DIK_CONVERT 0x79 /* (Japanese keyboard) */
#define DIK_NOCONVERT 0x7B /* (Japanese keyboard) */
#define DIK_YEN 0x7D /* (Japanese keyboard) */
#define DIK_ABNT_C2 0x7E /* Numpad . on Portugese (Brazilian) keyboards */
#define DIK_NUMPADEQUALS 0x8D /* = on numeric keypad (NEC PC98) */
#define DIK_PREVTRACK 0x90 /* Previous Track (DIK_CIRCUMFLEX on Japanese keyboard) */
#define DIK_AT 0x91 /* (NEC PC98) */
#define DIK_COLON 0x92 /* (NEC PC98) */
#define DIK_UNDERLINE 0x93 /* (NEC PC98) */
#define DIK_KANJI 0x94 /* (Japanese keyboard) */
#define DIK_STOP 0x95 /* (NEC PC98) */
#define DIK_AX 0x96 /* (Japan AX) */
#define DIK_UNLABELED 0x97 /* (J3100) */
#define DIK_NEXTTRACK 0x99 /* Next Track */
#define DIK_NUMPADENTER 0x9C /* Enter on numeric keypad */
#define DIK_RCONTROL 0x9D
#define DIK_MUTE 0xA0 /* Mute */
#define DIK_CALCULATOR 0xA1 /* Calculator */
#define DIK_PLAYPAUSE 0xA2 /* Play / Pause */
#define DIK_MEDIASTOP 0xA4 /* Media Stop */
#define DIK_VOLUMEDOWN 0xAE /* Volume - */
#define DIK_VOLUMEUP 0xB0 /* Volume + */
#define DIK_WEBHOME 0xB2 /* Web home */
#define DIK_NUMPADCOMMA 0xB3 /* , on numeric keypad (NEC PC98) */
#define DIK_DIVIDE 0xB5 /* / on numeric keypad */
#define DIK_SYSRQ 0xB7
#define DIK_RMENU 0xB8 /* right Alt */
#define DIK_PAUSE 0xC5 /* Pause */
#define DIK_HOME 0xC7 /* Home on arrow keypad */
#define DIK_UP 0xC8 /* UpArrow on arrow keypad */
#define DIK_PRIOR 0xC9 /* PgUp on arrow keypad */
#define DIK_LEFT 0xCB /* LeftArrow on arrow keypad */
#define DIK_RIGHT 0xCD /* RightArrow on arrow keypad */
#define DIK_END 0xCF /* End on arrow keypad */
#define DIK_DOWN 0xD0 /* DownArrow on arrow keypad */
#define DIK_NEXT 0xD1 /* PgDn on arrow keypad */
#define DIK_INSERT 0xD2 /* Insert on arrow keypad */
#define DIK_DELETE 0xD3 /* Delete on arrow keypad */
#define DIK_LWIN 0xDB /* Left Windows key */
#define DIK_RWIN 0xDC /* Right Windows key */
#define DIK_APPS 0xDD /* AppMenu key */
#define DIK_POWER 0xDE /* System Power */
#define DIK_SLEEP 0xDF /* System Sleep */
#define DIK_WAKE 0xE3 /* System Wake */
#define DIK_WEBSEARCH 0xE5 /* Web Search */
#define DIK_WEBFAVORITES 0xE6 /* Web Favorites */
#define DIK_WEBREFRESH 0xE7 /* Web Refresh */
#define DIK_WEBSTOP 0xE8 /* Web Stop */
#define DIK_WEBFORWARD 0xE9 /* Web Forward */
#define DIK_WEBBACK 0xEA /* Web Back */
#define DIK_MYCOMPUTER 0xEB /* My Computer */
#define DIK_MAIL 0xEC /* Mail */
#define DIK_MEDIASELECT 0xED /* Media Select */

/*
* Alternate names for keys, to facilitate transition from DOS.
*/
#define DIK_BACKSPACE DIK_BACK /* backspace */
#define DIK_NUMPADSTAR DIK_MULTIPLY /* * on numeric keypad */
#define DIK_LALT DIK_LMENU /* left Alt */
#define DIK_CAPSLOCK DIK_CAPITAL /* CapsLock */
#define DIK_NUMPADMINUS DIK_SUBTRACT /* - on numeric keypad */
#define DIK_NUMPADPLUS DIK_ADD /* + on numeric keypad */
#define DIK_NUMPADPERIOD DIK_DECIMAL /* . on numeric keypad */
#define DIK_NUMPADSLASH DIK_DIVIDE /* / on numeric keypad */
#define DIK_RALT DIK_RMENU /* right Alt */
#define DIK_UPARROW DIK_UP /* UpArrow on arrow keypad */
#define DIK_PGUP DIK_PRIOR /* PgUp on arrow keypad */
#define DIK_LEFTARROW DIK_LEFT /* LeftArrow on arrow keypad */
#define DIK_RIGHTARROW DIK_RIGHT /* RightArrow on arrow keypad */
#define DIK_DOWNARROW DIK_DOWN /* DownArrow on arrow keypad */
#define DIK_PGDN DIK_NEXT /* PgDn on arrow keypad */

[Saffith]

Here's something:

vkey = MapVirtualKey(scancode, 1);

GetKeyboardState(keystate);
update_shifts(keystate);

/* TODO: shouldn't we base the mapping on vkey? */
mycode = hw_to_mycode[scancode];

Indeed they should, and in Allegro 5, they do. I can't just replace the old file with the new one, but they might have an easy fix in SVN. The repository's unreachable at the moment, though...

Edit: Found a mirror. Doesn't look like it'll be as simple as that, but I think I can work out what needs changed.

[Shoelace]

Thanks for all of the hard work you putting into this. It definitely is a bad bug for us Win 7 users. >_<

[Saffith]

Of course. I'm kind of surprised it didn't come up sooner, though. Microsoft must've changed something, but I wonder why?

So, here, try this: http://www.mediafire.com/?9mjob21k36m334d
It definitely doesn't work quite right, so back up the current one first. But it should work well enough to get into the string editor and test those keys. If they're working now, I'll try and finish it up.

[Gleeok]

and in Allegro 5, they do.

That would be so great if we could use allegro5 instead of 4.237 or whatever altered version we have now. :(

I managed to get zc working with allegroGL (minus the wacked out palettes) way back when. Yeah, that was a stupid idea. lol.

[Colossal]

Of course. I'm kind of surprised it didn't come up sooner, though. Microsoft must've changed something, but I wonder why?

So, here, try this: http://www.mediafire.com/?9mjob21k36m334d
It definitely doesn't work quite right, so back up the current one first. But it should work well enough to get into the string editor and test those keys. If they're working now, I'll try and finish it up.

No luck, I'm afraid. :( The same keys are still inaccessible for me. Still, It's good to see the effort being put into fixing this persistent bug.

EDIT: Just in case this helps, the arrow keys don't work with this DLL, though strangely, the numpad arrow keys do.

[Saffith]

The changes are more extensive than I realized... I don't think there's any way I'll come up with a file that works for everyone. Even just creating one with an alternate key mapping is proving difficult.
Did what I could, though. Try this: http://www.mediafire.com/?9w0tbl7u7ln0ks0
Probably not perfect, but it should be better.

[Colossal]

Some good news: the backslash and apostrophe are now working. ` is also available, but it continues to type more of them as though you are holding down the key until you hit another key. The arrow keys work with this DLL.

= still dosen't work, neither does ~, +, {, }, |, or " (all require shift to type, although numpad + works).

Progress has been made, though, and hopefully, this can eventually be fixed for good, even if it requires a manual DLL replacement.

EDIT: Other characters that require shift, such as shift + 1 through 0, <, >, ?, :, capital letters, etc., still work.

[Saffith]

Probably too much to hope that it'll work, but see what this one does: http://www.mediafire.com/?bsr2p46q36zb7gm

[Colossal]

Probably too much to hope that it'll work, but see what this one does: http://www.mediafire.com/?bsr2p46q36zb7gm

No go, unfortunately. This DLL behaves the same as the original one (as in, the one in the beta 18 download).

[Saffith]

Still at it. Trying to fix this in a sensible way hasn't been working, so here's another shot at the stupid way: http://www.mediafire.com/?8nw647z5nypjk58
Even if the keys are right in that one, the ` key will still stick. I have no idea what to do about that.

[Gleeok]

Just curious but what is the output if one of you guys run this? :



#include <iostream>
#include <string>

int main( int argc, char *argv[] )
{
using namespace std;
string cbuf;

cout << "enter a string and press [Enter]:" << endl;
cin >> cbuf;
cout << "You entered keycodes:" << endl;

for( int i(0); i < cbuf.size(); ++i )
{
const char c = cbuf.at(i);

cout << c;
cout << "\t";
cout << int(c);
cout << "\t";
for( int j(0); j < 8; ++j )
{
cout << int(((0x01 << j) & c) ? 1 : 0);
}
cout << "b" << endl;
}

cin >> cbuf;

return 0;
}


EDIT: ..Actually I suppose this would work fine.... durr brain fart.. I wonder if it's a DX7 thing and could be fixed by linking to DX8..? I also wonder if there is an keyboard layout emulator or something...

Also look at post above. ^^^

[Shoelace]

Same thing happens Saffith. The same issue exact keys are going the same thing. One key that wasn't mentioned in the first post was "+" that doesn't write anything. Just throwing that out there. One thing I wanted to mention about the allergo that you provided Saffith it messed up some other keys: When pressing "E" it shows: ":", and "f" -> "1" and "c" -> "6".

[Gleeok]

OK! das mine turn now yah! Lets try a simpler approach to this. ;)

The GUI will show you what you are pressing, and the logger will output various scancode data. The first time you run it you can mess around to see what exactly doesn't work right. Then run it again and press all the afflicted keys, mash ESC, then post the log here. :)


http://www.mediafire.com/file/c3bx1anb90bqd7n/msvc_alleg_exkey.zip

[Colossal]

Alright, here is a log file. (http://dl.dropbox.com/u/13242284/allegro.log) I pressed the malfunctioning keys in this order: ` = [ ] \ '

Pressing = didn't seem to do anything, nor did it show up in the log.

[Gleeok]

According to that the '[', ']' keys should work fine.. WTF?? :confused:

..Now to figure out where the other ones went wrong...

[Colossal]

To clarify, there are 6 keys that I pressed, but only 5 corresponding readkey() entries.
First readkey() was when I pressed `
= did not produce a readkey() entry.
Second readkey() was when I pressed [
Third readkey() was when I pressed ] (it produces [ instead)
Fourth readkey() was \
Fifth readkey() was '
And then the readkey() for esc.

Hope it helps.

[Colossal]

I finally decided to figure out how to compile Allegro, and I might have found a way to fix this problem... by modifying the scancodes before they are processed. Using the source code for Allegro 4.2 and Gleeok's test program, I was able to produce the correct outputs on Windows 7. If someone could merge what I've changed with your code, I could test and confirm whether or not this works for ZC/Zquest.

EDIT: Detected the OS version so that the changes only apply to Windows 7 (And Windows Server 2008 R2, apparently). Probably not the best way to do this, but I don't have any better ideas right now. The ~ key sticks too... not sure what to do about that.

[Gleeok]

That's great! Thank you. :)

It was extremely difficult to make sense out of this issue from a standpoint of having everything work correctly for you, but not for some select other users. Very frustrating.

Do you have a patch with the changes or...?

I don't believe any 4.X to 4.40 allegro dll will work with zc without an error, as we're using a modified version of 4.22 that has been "bug-fixed" numerous times over the years. Although I don't see why we can't make the source code to that available for download.

[Colossal]

Well, I do have the modified wkeybd.c file. Link. (http://dl.dropbox.com/u/13242284/wkeybd.c) My changes are at the beginning of the handle_key_press and handle_key_release functions.

I'll be keeping the old DLL anyway, just in case the underlying cause gets fixed at some time. I wish I knew of a better way to do this, but it's my first time working with the Win32 API. This will hopefully work for now though.

EDIT: Changed the scancodes to their hex values. Also, there are a couple of issues:
-If the program is run in compatibility mode (Ex: For Windows XP), this method won't work in its current form because the returned OS version will be different.
-The OS version info should probably be retrieved only once (and still checked every time), though I'm currently not sure what function should do that.

[Tamamo]

I'm having this same problem. Now that I know what's causing it I feel relieved that it's being worked on. :)

[Gleeok]

Well, I do have the modified wkeybd.c file. Link. (http://dl.dropbox.com/u/13242284/wkeybd.c) My changes are at the beginning of the handle_key_press and handle_key_release functions.

I'll be keeping the old DLL anyway, just in case the underlying cause gets fixed at some time. I wish I knew of a better way to do this, but it's my first time working with the Win32 API. This will hopefully work for now though.

EDIT: Changed the scancodes to their hex values. Also, there are a couple of issues:
-If the program is run in compatibility mode (Ex: For Windows XP), this method won't work in its current form because the returned OS version will be different.
-The OS version info should probably be retrieved only once (and still checked every time), though I'm currently not sure what function should do that.

I'm thinking just a simple callback in those spots so future changes won't require an allegro rebuild. ;) Maybe a win_7_keyboard_fix option in the config file should suffice.

EDIT: Ah, just remembered I can't compile a compatible dll for zc b18 or rc1 right now to test those. Saffith? :P

[Tamamo]

I'm using vista, so you would need to have a dll for each os. Or at least for the ones that report this bug. I believe it's a driver issue, and has nothing to do with windows 7.

[Colossal]

Wait a sec, you're seeing the bug on Vista? The weird thing is, that's exactly what I would expect, but I have a Vista computer and the bug does not manifest on that one... maybe the version checking should not check the minor version number for now in that case.

[Tamamo]

I have a laptop so that's probably why. :P

[Colossal]

This is a long shot, but would you happen to be running 64-bit Vista? My Vista computer is 32-bit.

[Tamamo]

This is a long shot, but would you happen to be running 64-bit Vista? My Vista computer is 32-bit.

Nope, I'm using 32-bit. 64 bit sucks

[Colossal]

I found a way to stop the tilde key from sticking (it's ugly, but it works and I'm not even sure why, lol). The only thing is that the key will only register every 2nd press, but that's probably better than it sticking and flooding the screen with the same character.

Link to wkeybd.c (http://dl.dropbox.com/u/13242284/wkeybd.c). Changes are at the beginning and the end of handle_key_press and the beginning of handle_key_release. The changes in their current state could produce an alternate DLL only for those experiencing this bug.

I'm also considering uploading the DLL in case anyone else is interested in checking it out to make sure there aren't any surprises such as having to make another modification to the key mapping (or new bugs with the input). The DLL wouldn't work with ZC though; it could be tested with the test program Gleeok uploaded earlier in the thread. The MSVC++ 2010 redistributable would also have to be installed because that's what I used to compile it, which is another reason why I would leave compiling a ZC-compatible DLL to the devs.

[Saffith]

Sorry to take so long with ths...

http://www.mediafire.com/?bnxlnbs1zl9ret4

Messes up my keyboard a bit, so that's a good sign.

[Colossal]

Sorry to take so long with ths...

http://www.mediafire.com/?bnxlnbs1zl9ret4

Messes up my keyboard a bit, so that's a good sign.
That did it. The keys are working perfectly now. :D Thanks Saffith.

EDIT: Posted at PureZC. Hopefully this works for everyone else experiencing this bug.

[Tamamo]

Houston I am experiencing no problems with this dll. We have had a successful take off. Over.

[Gleeok]

Would it be possible to fix this using keyboard_lowlevel_callback instead to avoid extra dll files? http://www.allegro.cc/manual/4/api/keyboard-routines/keyboard_lowlevel_callback

[Colossal]

Just because I felt like it, I fixed the tilde key so it now works every time it is pressed. It's a weird key; it's as though each press alternates between calling handle_key_press and handle_key_release. So I made a few changes to handle_key release to get it to work the other half of the time. I updated the file I posted. It's certainly not a priority fix, but maybe if another DLL is compiled for whatever reason...


Would it be possible to fix this using keyboard_lowlevel_callback instead to avoid extra dll files? http://www.allegro.cc/manual/4/api/keyboard-routines/keyboard_lowlevel_callback
It looks like by the time the callback is reached, the incorrect scancodes will have screwed up the input completely. It wouldn't work with my method, at any rate, because I correct the incorrect scancodes much earlier than that. Though only a few keys conflict ([, ], \, maybe ~).

[Gleeok]

J
It looks like by the time the callback is reached, the incorrect scancodes will have screwed up the input completely. It wouldn't work with my method, at any rate, because I correct the incorrect scancodes much earlier than that. Though only a few keys conflict ([, ], \, maybe ~).

Yeah I was pretty sure that was the case but it was worth a shot. That's the reason why the modified exkeys I posted gave really confusing (not to mention almost worthless) results.

You have some programming experience I take it?

[Colossal]

I have some programming experience with .NET.

Exkeys was still useful in figuring out what the incoming hardware scancodes were (it was actually displaying Allegro key codes, so I just used the conversion array to get the hardware codes from that). The keyboard_lowlevel_callback would also be passed an Allegro key code.

EDIT: I surrounded my changes with a boolean. Maybe this can be used somehow.

[Colossal]

I thought I'd revisit this issue in case anyone's up for creating a single DLL that can work for everyone. I created an Allegro function and customized a version of exkeys with which I can toggle the keyboard fix at will and it appears to work perfectly. A function call would be all that's needed to activate the fix. I just hope I didn't break compilation on other platforms.

EDIT: I don't see any issues (on Windows), so these are my changes:
wkeybd.c (http://dl.dropbox.com/u/13242284/wkeybd.c): Changes are in handle_key_press(), handle_key_release(), and the use_keyboard_fix variable declaration.
keyboard.h (http://dl.dropbox.com/u/13242284/keyboard.h): Added this line.

AL_FUNC(void, set_keyboard_fix, (int use_fix));
keyboard.c (http://dl.dropbox.com/u/13242284/keyboard.c): Added the use_keyboard_fix variable and the set_keyboard_fix() function.
allegro.def: Added this line (or whatever will work):

set_keyboard_fix @1408

Then, a program can call set_keyboard_fix(1) to activate the fix or set_keyboard_fix(0) to deactivate it (deactivated by default).