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

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

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

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.

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. ^^^

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".

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

Alright, here is a log file. I pressed the malfunctioning keys in this order: ` = [ ] \ '

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

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

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

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.

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.

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.

Well, I do have the modified wkeybd.c file. Link. 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 having this same problem. Now that I know what's causing it I feel relieved that it's being worked on. 😊

Colossal wrote:Well, I do have the modified wkeybd.c file. Link. 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.

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

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.

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.

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

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

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

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. 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.

Sorry to take so long with ths...

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

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

Saffith wrote:Sorry to take so long with ths...

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

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

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

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

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

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...

Gleeok wrote: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 wrote: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 ~).

You have some programming experience I take it?

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.

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: Changes are in handle_key_press(), handle_key_release(), and the use_keyboard_fix variable declaration.
keyboard.h: Added this line.

AL_FUNC(void, set_keyboard_fix, (int use_fix));

    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).