Communicating with other programs

[Russ Srole]

Guys,

I'm researching something that, at this point is beyond my knowledge
base. Here's the project:

We have a control panel connected via an rs-232 port. I would write
a program that looks like the control panel and allows the user
to assign either keypresses or mouse events to a particular button(s).
The tricky part is this needs to act like a DOS macro TSR. The user
would click on a button on my program, it would then minimize itself,
I would then have to identify the program that is now got the focus
and wait for a keypress or mouse click. Essentially I would need to
eavesdrop on the other program (not something I've written) and get
the message. Then I restore my program to "normal" size and let
the user program some more buttons. The other half of this, is
the "play back" side of things. When my program is minimized and
the user pushes a button on the control panel, I'm to send that
keypress/mouse event to the top level window. I'm very familiar
with the comm port stuff and working with this control panel, it's
the communicating with and sniffing the events of the other program
that I has me clueless. Anybody have any suggestions on where to
look and start?

TIA,
Russ Srole


------------------

[Michael Mattias]

When you say, "eavesdrop" on a program you have not written, the real question is, " for what are you listening?"

For programs to communicate with each other, they need to be cooperating, which usually means they were written with that purpose in mind.

Some things you can do, without toomuch difficulty:

-Start a program and wait for it to finish
-Interrogate a program to see if it is in "idle" state.
-See if a disk file created/maintained by that program has been created or changed
-(TSR-like) intercept Windows messages to that program

Other than that (and I may have forgotten a couple), if the programs on which you wish to eavesdrop neither "broadcast" nor have a defined API, your task is somewhat daunting.

If you can describe the other program's "events" or "status," maybe someone can give you a push in the right direction.

(This is a fascinating question for me. But.. I wonder if your strategic design - that is, the"big picture" of your system architecture - may need some modification)



------------------
Michael Mattias
Racine WI USA
[email protected]

[Tom Hanlin]

The keywords you want are "hook" and "journal". The techniques involved
are powerful, but have their limitations, and are not really intended
for casual use.

Semen's posted some samples that employ Windows hooks.

The approach you suggest does not mesh well with Windows design. You may
want to consider whether there are other ways of getting there from here.

------------------
Tom Hanlin
PowerBASIC Staff

[Russ Srole]

Michael,

The idea is that the folks who make the control panel would like
it to be able to send messages, keyboard and mouse clicks to programs
that do not support the control panel. The example they gave me is
Apple's Final Cut Pro for the Mac. They had a guy write a program
that when told to listen, could tell if the user pressed a key or
clicked on a button and store that information in it's data base.
Then when the user pressed a button on the control panel, this background
program would send that same message back to the top level program
(somehow) and it's as if the user did the keypress or clicked the mouse.

They would like the same sort of thing for windows, if it's possible.

In the DOS world I'd write a tsr that would be interrupt driven on
the comm port and when a button was pushed, convert it to a ascii
code and stuff the keyboard buffer.

Last night I searched Poffs and the win32api.hlp and found hints.
I see that you can enumerate all the top level windows and get the
titles. I think you can tell who has the focus, but haven't sorted
that out yet. I see you can send messages to other processes and
that might work for sending keypresses etc. But I haven't found
anything about eavesdropping on the keyboard and mouse events in
another process.

Any help is appreciated, even if it's a definitive "Can't be
done in Windows". At least I'll know to tell them, sorry can't help.

Thanks,
Russ Srole

------------------

[Russ Srole]

Tom,

Any and all suggestions are welcome! I guess the only thing we can
count on is that the programs that we'd like to send messages to,
aren't going to know we're there. So to narrow it down, how do we
know what messages to send when x control panel button is pressed
and how to we send it?

Thanks,
Russ Srole

------------------

[Chris Boss]

Russ;

The API function you want is SetWindowsHookEx !

But as Tom mentioned, care must be taken when using it. You
can mess up the entire OS with this function if you are not
careful.

You must take care to impliment the function (requires a callback
type procedure) exactly as the API docs recommend. Also you must
process the messages the hook receives with the minimum amount
of processing since too much code in your hook will significantly
slow down the system.

I suggest searching the web for examples of code which uses
SetWindowsHookEx and see how it is used. I usually enter the API
function name in my favorite search engine and then check out every
web site that shows up in the search.


------------------

[Russ Srole]

Chris,

Thanks, I'll do that.

Shameless plug for Chris: EzGui Rocks!

Russ Srole

------------------

[Michael Mattias]

The idea is that the folks who make the control panel would like
it to be able to send messages, keyboard and mouse clicks to programs
that do not support the control panel

Well, that is doable, and you could even do it in real time..but.. this assumes the "called" programs are cooperating to the extent that is ready for whatever Windows messages get sent. Most applications (my own included) will take - safely - as gospel that "if I get a click on control #123 I must be on screen B." When you blindly (poor choice of words, but in this case, maybe not so far from the truth) send a WM_CLICK message to a program, you are assuming that program is ready for that message at that time.

So we are back to "cooperating" programs again; in which case, there are better ways to engineer the system (e.g., provide an API for the control panel in a DLL. Have functions to set callback addresses, and to provide the callback address for user functions in the "Control Panel DLL.")

Design Assistance available here:


------------------
Michael Mattias
Racine WI USA
[email protected]

[Russ Srole]

Michael,

I agree that a cooperative method would be much better. In fact
this control panel is easy enough to deal with that it would make
more sense for the other programs to just support them. The maker
of the control panel could provide a DLL as you say and that would
be fine too. I guess there has been some problem convincing the other
guys to support the panel. I don't kown why, since they are in use
widely in the TV industry. Who knows?

Thanks for the offer. I might take you up on it.
Russ Srole



------------------

[Russ Srole]

Ok, I don't know if I'm going to do this job, but now I want to
know more about this stuff. I've got the enumerate windows part
working, but I haven't yet figured out which window has focus. I'm
also trapping the ascii keypresses thanks to Wyman Belts and the
code he posted in December 2000. Also thanks to Borje (again) for
Poffs. I did the search as Chris suggested and found a couple of
VB sites with good articles about setWindowsHookEx and the whole
chaining thing. More to come as this progresses.

Thanks for all the help & I'll take any more you care to give,
Russ Srole

------------------