Does anyone want to bug test a program?

[Inertially]

Seeing as how this wonderful community is mainly about keyboards and stuff, I thought that it would be a good idea to ask here.

I made some keyboard input program which displays key inputs amongst other things.

http://sites.google.com/site/inertially/keyscan

Download link: http://sites.google.com/site/inertially/files

If you are getting the COMCTL32.OCX error, download that also.

Suggestions are welcome.

[bsvP585hUO2Y6]

Inertially writes:

> Suggestions are welcome.

I don't see a license anywhere... Is the source code available?

[Mr.6502]

It might be handy to include instructions on the page that tell people how to register comctl32.ocx since just putting it in system32 or in the same folder as the exe won't make it work on all systems.

[FunkTrooper]

It appears to detect what key you're pressing based on your keyboard layout and not the scancodes of that key.  And it does not recognise keyboard layouts other than US QWERTY.

I use Colemak, and the keys it recognises are all wrong. For example, If I press *my* T key (which is labelled F), it will be recognised as a keypress of the key that is labelled T on the keyboard.  I know Colemak users may seem like a tiny minority to bother catering for, but presumably this bug would also affect users of AZERTY, QWERTY and even UK QWERTY users, to mention but a few.  It would probably be a better idea to read the scancodes, if that's even possible with a .NET app, which I assume is what this is (I really don't know much about Windows programming, even though I use little other than Windows myself).

EDIT: also, pressing Alt Gr is recognised as being a press of a combination of Left Ctrl and Right Alt. That's really interesting — I wonder if that's how Windows actually interprets a press of the Alt Gr key.

[FunkTrooper]

I've attached a screenshot to show what it's detected of my PC.  Although I have the same processor as you (a Q6600), it doesn't show up that model name like your screenshot does, even though it does detect other details about the CPU correctly.

It manages to get my RAM very wrong indeed — I do not have 0.125 GB RAM; infact, I have 4 GB.

The “Unknown Keyboard” in question is a Unicomp Customizer 104.

Seemingly, when taking a screenshot, the “log” part of the windows doesn't quite get screenshot correctly… I'm not quite sure how that happened.

Also, is there any chance of this being open-sourced. It would be very interesting to see how this is all done, if nothing else.

[ch_123]

EDIT: also, pressing Alt Gr is recognised as being a press of a combination of Left Ctrl and Right Alt. That's really interesting — I wonder if that's how Windows actually interprets a press of the Alt Gr key.

CTRL+ALT does the same thing as ALT-GR, so it would make sense.

[vils]

I just pressed AltGr + Del, it worked! Why have I been pressing 3 keys to guide windows through life for all these years.

[vils]

This thread is around a similar program, although this seems to be more promising.

[Mr.6502]

I've attached a screenshot to show what it's detected of my PC.  Although I have the same processor as you (a Q6600), it doesn't show up that model name like your screenshot does, even though it does detect other details about the CPU correctly.

It manages to get my RAM very wrong indeed — I do not have 0.125 GB RAM; infact, I have 4 GB.

The “Unknown Keyboard” in question is a Unicomp Customizer 104.

Seemingly, when taking a screenshot, the “log” part of the windows doesn't quite get screenshot correctly… I'm not quite sure how that happened.

Also, is there any chance of this being open-sourced. It would be very interesting to see how this is all done, if nothing else.

Show Image

That screenshot is interesting.  Looks like it took the screenshot in the middle of the window redrawing.  On my computer when I do a screenshot of the program, the PrtScr button is lit up but the "log" part hasn't been updated to include the PrtScr button press yet.

[sixty]

I always thought ASCII Shower was an unfortunate name.  Sounds like it came from a Porn site.

Before I even look at this program is the author going to be charging for it?

It says its freeware in the about box.

Btw, Gave this a try yesterday, I really like it so far, especially since its portable and does not need any install. But yes.. it would make more sense if the keys pressed are being recognized by their bios keycode.

[Rajagra]

Sooo... are we satisfied this isn't a keylogger?
It checked out OK with Kapersky and Ad-Aware, but I held back from running it. Sorry to be so mistrusting but linking a download in someone's first post on a forum tends to arouse suspicion.

[Inertially]

Thanks for the feedback.

I haven't been replying because I've been worrying about other things such as entering first year college, in which I think I'm screwed, and working on this can take up a lot of time, maybe because I'm mentally challenged (in a way)...

As for how the program works, anything you need to know or would want to know is available here:
http://msdn.microsoft.com/en-us/library/ms645530%28VS.85,loband%29.aspx

There are some major bugs in the beta.

I chose to do a look up from the virtual key code instead of  scan code because virtual key is device-independent whereas scan code can be specific/vary from keyboard  to keyboard.

Whether virtual-key is used or scan code is used, a new virtual keyboard layout (UI) would have to be created in order to support unique key layouts.

In your case, I don't think VKey vs Scan code is causing the error.  The scan code for each key does not change when you enable the Colemak layout, assuming that you are using the application that remaps each key from QWERTY to COLEMAK and not a native COLEMAK keyboard.

The Colemak remapping app uses a low-level keyboard hook to block key input from the keyboard and then injects the COLEMAK equivalent of that key (F to T) with probably the SendInput() or keybd_event() API.

Because both applications use keyboard hooks, the results can be funky, or vary, depending on which application is ran first.
And KeyScan sometimes detects both the normal and injected key inputs.
Also there's mistake in interpreting key up/down.

The program does log keys (should be apparent), but it doesn't send them to anyone or anything.  This isn't a keylogger.

[FunkTrooper]

In your case, I don't think VKey vs Scan code is causing the error.  The scan code for each key does not change when you enable the Colemak layout, assuming that you are using the application that remaps each key from QWERTY to COLEMAK and not a native COLEMAK keyboard.

The Colemak remapping app uses a low-level keyboard hook to block key input from the keyboard and then injects the COLEMAK equivalent of that key (F to T) with probably the SendInput() or keybd_event() API.

Because both applications use keyboard hooks, the results can be funky, or vary, depending on which application is ran first.
And KeyScan sometimes detects both the normal and injected key inputs.
Also there's mistake in interpreting key up/down.

That's not right at all.  There is no “Colemak app”, it's just a keyboard layout created using MS Keyboard Layout Creator.  The same problem is seen with this program when using Dvorak or Azerty keyboards.

[lowpoly]

EDIT: also, pressing Alt Gr is recognised as being a press of a combination of Left Ctrl and Right Alt. That's really interesting — I wonder if that's how Windows actually interprets a press of the Alt Gr key.

I remember getting problems when I used Autohotkey to redefine

CapsLock::LCtrl
LCtrl::LWin

Then AltGr would act up. Why couldn't they use RCtrl which I never use.

[Inertially]

That's not right at all.  There is no “Colemak app”, it's just a keyboard layout created using MS Keyboard Layout Creator.  The same problem is seen with this program when using Dvorak or Azerty keyboards.

I was looking at  http://sourceforge.net/projects/pkl/files/

There is a portable Colemak remapping app.