Thread: Windows 7 Machine: Convert Simple "C" Program to Windows "Threaded" Program

Let me understand this: You want to do a GUI application for a keyboard because you want to use the mouse instead of pressing keys?

flp1969: No. I don't want to make a GUI keyboard on the screen so I can tap the keyboard buttons instead of pressing keys (if that's what you mean).

I have a "C" Console Program that I wrote to emulate a proprietary, native keyboard, and now I just want to convert it to a Windows Program. The Console Program works fine, but it would be better as a Windows Program because I could move the Cursor to the graphical editing point on the screen much quicker (and maybe there would be other benefits like being able to select objects easier than even the Native System).

The other thing is - the Console Program is running on a Windows 7 desktop which is also used for other Lab-Software Functions ... and when the Console Window loses focus (switching to another app), the Keyboard Emulator program stops working until you click the mouse back onto the Console Window. This is not a big deal, but again ... if it was a Windows Program it would work much better.

Salem: Do I have the source code for the other Lab-Software Functions? No. And one of these other programs - which is already a windows program (XP) with a primitive GUI - is in desperate need of a re-write/upgrade because it's not compliant with audit trail requirements, which results in our having to maintain Log Books with paper signatures and monthly reviews, which sometimes result in further paperwork if the rules are broken .. it's just a royal PITA. That one needs to be something like 6 clients talking to any of 50 proprietary Controllers, and reporting every action taken to a central database, where all the auditing and reporting could be centralized and easily handled.

But back to the Keyboard Emulator ... I didn't realize I could add Mouse control to a Console Program. OK.

One other thing: the proprietary Graphics Box this Emulator talks to can sometimes send data back. AFAIK, it might only be the BEEP code "7" (to warn of improper input). Can my Console Program both write AND read at the same time ... or does that necessitate turning it into a GUI program? Doesn't it need to be an "Event Driven" program in order to not "block"? Earlier, when I was playing around with it, I had a separate Console Program that opened an Input Buffer to just read data from the Graphics Box during testing ... to capture what it might've been sending back. But the program would "sit" at the ReadData (input) instruction (blocking), so I left it out of Keyboard Emulator for now (so it would continuously read keyboard data, convert it, and send it out to the Graphics Box).

Can I re-introduce the ReadData instruction, and if so ... how do you stop it from "blocking"?