Keyboard / Mouse Input Device Design??

On Mon, 30 Oct 2006 20:37:41 -0600, "Peter Olcott"


Is this a homework question? I haven't seen these devices for years! The old macro keyboards that inserted between keyboard and computer were probably under $100. Modern solution is use something like Macro Express <http://www.macros.com/ which is much more convenient to use.
--
Mark

Add pictures here
<% if( /^image/.test(type) ){ %>
<% } %>
<%-name%>
Add image file
Upload
wrote:

One of the applications that I am creating with my www.SeeScreen.com patented technology is a better Macro Recorder than can otherwise exist. Since SeeScreen let's any application always be able to intelligently see what's on the screen, now for the first time a Macro Recorder can reliably operate the mouse. Before SeeScreen Macro Recorders were blind, and could not "see" where to click the mouse.
Add pictures here
<% if( /^image/.test(type) ){ %>
<% } %>
<%-name%>
Add image file
Upload
Peter Olcott wrote:

I see. Let me clarify for the other readers - you are _not_ proposing to recognize any arbitrary "text". It is possible to render text in Windows using a font not known by the system using bit-blt on internally rendered bitmap. Certainly you would not be able to recognize a custom "dingbat font".
That said, I can vouch for the value of your application (if it actually works. :])
Most macro recorders today are somewhat disfunctional. (Macro recorders monitor, in software, the input stream to Windows, and attempts to replay the stream back after the computer has been rebooted to get the application into the state it assumed when a human entered the input).
The reason that they are broken has primarily to do with timing - when it comes times to playback the keystrokes, they have no idea how rapidly the application is responding to playback. So the macro recorder might replay input too fast, playing keystrokes that were meant for a window that has not come alive yet. The keystrokes are then lost. The operator of the macro recorder will try to combat this by guessing how long it takes a Window to be "born" and "come to life", waiting that amount of time before playing input to that Window. But this is error prone. Raise or lower the CPU peformance, and it breaks.
So Peter's application apparently takes a snapshot of the screen, finds all the windows, finds the title bars in the windows, edit boxes, etc. and presents that data when it is requested by a function that wants it. In this case, the operator of the macro recorder will no longer have to guess how long it takes windows to pop up. He will simply say, "Wait until there is a window with "Google Talk" in the title bark".
If this is what you are doing, and you are not doing generalized OCR, which you said on your site you were not, then I am a bit puzzled, as it would be possible to do the same by intervention into the GUI subsystem of Windows. And unlike the frame grab method, where you watch the pixels and therefore cannot "keep up" with state transitions on the screen, you would know pretty much the "exact" state of the screen at all times.
-Le Chaud Lapin-
Add pictures here
<% if( /^image/.test(type) ){ %>
<% } %>
<%-name%>
Add image file
Upload

Polytechforum.com is a website by engineers for engineers. It is not affiliated with any of manufacturers or vendors discussed here. All logos and trade names are the property of their respective owners.