New project help!

[apathy_next2]

Hello everyone,

I took some C++ in college, but its been a while now.

I'm trying to write a program, something very similar to the microsoft onscreen keyboard. Basically what I want to do is test a keyboard to make sure all the keys work. I can use the micrsoft one, but there are some custom keys to keyboard that I am using, plus it has a track ball(and keys associated to that. Trackball should be testable with the mouse, but I want to the test the keys on the trackball as well. This keyboard is USB!

My question is that, is this something that will be easily done with Visual C++? Or should I look for another program which will make it easier for me to do this. I just need to do something really basic and nothing fancy at all. I will have to relearn pretty much from scratch C++ atleast, although it should not be that crazy hard since I have past experience with it.


Thank you

 

[Markbnj]

I don't know if "easily" is the word I would use for anything done in C++, especially if it's been a few years since you used it. Do you need to read the press state of every key, or just the ones that correspond to ASCII characters? In C++ you have getch(), scanf(), and cin, but that probably won't cover everything you need. Function keys, for example, generate a platform-dependent sequence of escape characters. Control and alt keys don't generate anything to stdin at all, until they are pressed in concert with another key that they modify.

 

[apathy_next2]

I don't know if "easily" is the word I would use for anything done in C++, especially if it's been a few years since you used it. Do you need to read the press state of every key, or just the ones that correspond to ASCII characters? In C++ you have getch(), scanf(), and cin, but that probably won't cover everything you need. Function keys, for example, generate a platform-dependent sequence of escape characters. Control and alt keys don't generate anything to stdin at all, until they are pressed in concert with another key that they modify.

I just need to have some kind of GUI, where if a key is pressed let's say that key turns a different color on the screen so I know that it works. Just a way to test it. If C++ will be hard, which program would make it simple?
Im willing to use dos if thats what it takes

 

[TecHNooB]

can't you just print something to the console when the right buttons are pressed? no need to make a gui if you don't have to.

 

[Leros]

I would use C#. Its easier to use than C++ and its syntax is similar enough to C++ that your previous knowledge will translate over.

Unless you already have a strong knowledge of C++ or need the performance, I wouldn't suggest using it.

 

[IHateMyJob2004]

Clifff notes:

1) You need a hook into the Windos OS where you can steal key strokes. Easy

2) You need to be "always on top". Easy other than when you are competing iwth other apps to be on top.

3) new to C++

Ya, you just need to learn a bit about input and output. Read up on some hello world apps. Go on from there.

 

[Markbnj]

I just need to have some kind of GUI, where if a key is pressed let's say that key turns a different color on the screen so I know that it works. Just a way to test it. If C++ will be hard, which program would make it simple?
Im willing to use dos if thats what it takes

Ok, so I'll take your answer to mean you need the press/release state of every key on the keyboard. This isn't simple to do, and how you do it depends on what framework you're using, so that's the first decision.

Doing the GUI that you describe in C++ is non-trivial. Even though it seems like a simple GUI, doing it in native Win32/C++ will take a ton of code. Doing it in MFC will take a ton of learning. Either way you're out a ton. Also, if you go native Win32/C++ then getting the key press/release state is complicated too. So I think you should rule out C++.

So that leaves C# or Visual Basic (I'm ignoring a few other alternatives). You should use C# because it's better than VB.

The last decision is what GUI framework to use: Windows Forms or Windows Presentation Foundation (WPF). WPF is newer, neater, and makes getting the key info about as easy as it will get. In either you can use a visual designer to create much of your window and related controls. For fine-tuning the GUI WPF would also require you to learn XAML.

Someone else mentioned just dumping it to a console window, and if you want to do that you can skip the GUI altogether, but you'll still have to learn the basics of creating a program in C#. You can download Microsoft Visual Studio Express C# Edition for free and it will give you everything you need.

Once you have the main program and GUI working we can talk about how to get the keypresses (basically you hook an event on your window).

 

[sourceninja]

Hell you could do this in javascript.

Detect keypress (onKeyDown), get key (keyCode), change css on a div that represents that key to make the background a different color. Should be fairly trivial for any language.

 

[EagleKeeper]

Win32 has a message for WM_KEYDOWN and WM_KEYUP.

All you have to do is translate the keycode

 

[Markbnj]

There are, or at least were, some significant issues with both those approaches. Javascript key down support used to vary quite a bit across browsers in how extended and special keys were handled or not handled. The WM_KEYDOWN message also has some funkiness with respect to special keys.

Years ago I wrote an input handler for the keyboard at the interrupt level for a game framework. Basically you get an interrupt from the 8042 and then read a couple of ports. That gets you everything but you still have to deal with differences among keyboards.

I'm not sure any of the higher level methods will reliably get press/release for every key on the keyboard.

 

[Fallen Kell]

Yeah, I was going to suggest the same thing about just getting it at the interrupt level (but this was back in PS/2 days, USB keyboards work differently). I am not sure how easy or hard it would be to do the same with a USB keyboard. With the PS/2, every keypress caused a hardware interrupt, which you could trap and handle on your own.

 

[Markbnj]

I assume they must be emulating that interrupt for USB keyboards but I'm not sure.

 

[Fallen Kell]

I don't think so. The way it works from my understanding is that there is a polling rate where the keyboard driver needs to actually check for the data on the USB bus, no actual interrupt occurs when the keys are pressed, so there is no interrupt to trap. It is one of the reasons why PS/2 keyboards are still recommended for gaming (as well as the fact that the USB bus has hard limitations as to how many keys can be pressed at the same time, again due to the fact that it is polling for the data, and not a hardware interrupt, most USB keyboards are 4KRO or at absolute most 6KRO, where-as PS/2 keyboards are NKRO).

But like you said, it is possible that it then places this data on the proper registers as keyboard input which then causes the hardware interrupt, but I really don't know.

 

[Fallen Kell]

Also, I found one of the sites I used back in the day. It had a really good overview of how keyboards worked as well as some sample code for using a 68HC705J1A MCU chip to process keyboard signals and convert to ASCII. It has most of the keyboard signal codes.

http://www.beyondlogic.org/keyboard/keybrd.htm

 

[Markbnj]

But like you said, it is possible that it then places this data on the proper registers as keyboard input which then causes the hardware interrupt, but I really don't know.

Yeah that's what I was thinking would be needed to support older software. But it wouldn't overcome the limitations you described.