The computer in question is not set up with networking.
If the computer is set up with networking, then you can use UDP
over 127.0.0.1 (sockets).
You can also use files, maybe something like this. The sender, A,
can write a file "tempAToB", wait until there is no "AToB" and then
rename "tempAToB" to "AToB". The receiver, B, might look for the
new "AToB", read it, and delete it. For very short messages, just
rename the file and look for changes. You can also use multiple
files as a queue in alphabetical order.
Dar... I understand the plan here. My concern with this is the
constant disk access that would need to take place. The information
that needs to be exchanged between these two apps is directly
connected to the users experience. So when the user presses a button
on App A, they expect to see a rather immediate response. That
response will be occurring in App B, but I need it to look like it's
all one application. So App B needs to be polling every second or so,
as does App A. Is this too much disk access or acceptable?
I've played around a little with read/write - to/from processes, but
can't get the hang of it yet. Having had no experience with those
functions, it may take a bit of work to get that to go. Same goes for
sockets... no experience with that either.
And, of course... I'm really hoping to not spend a lot of hours on
this issue.
Rob.. I'll look into Jan's socket communication library. I'm assuming
that it is accessible to anyone who signs up with that group. Is the
use of that approach fairly straightforward?
Also hoping to hear back from Dave on the ISM module.
Thanks all.
Richard
_______________________________________________
use-revolution mailing list
[email protected]
Please visit this url to subscribe, unsubscribe and manage your subscription
preferences:
http://lists.runrev.com/mailman/listinfo/use-revolution
