RE: Screen Update via Separate App

Here is a technique I have used many times for inter-process communication,
where the two applications can be on the same machine, on the same LAN, or
even connected via the Internet. Use a TCP/IP socket. Once established, a
socket is a private, bi-directional link between the two appliations. To do
that you will need a socket library - you can download the free SocketWrench
package from Catalyst Software (www.catalyst.com). They have excellent
documentation in on-liine help, good examples in various platforms (.NET,
VB6, etc.) Take a look at their 'chat' sample code in the Visual sub-folder.
(it's in VB but you will be able to follow it and implement it in VBA quite
easily. Essentially the application doing the browsing sends a message with,
say, the key of the record you want to display to the remote machine. The
code to send the message should be put in the form's OnCurrent event. The
receiving machine accepts the message, retrieves the appropriate record(s)
and displayst. For example, the message could be a SQL query, or just the
WHERE clause, etc.

For same machine installation, the IP address is the loop-back address -
127.0.0.1 For other configurations you would need the actual IP addresses.

Outline for setting it up:

Receiving application:
Drag two socket controls to the form - they are invisible. Name one
sock_Listener and the other sock_Reader. Set up the Listener to "listen" to
a port of your choosing - pick a number above 1024 - let's say 3333. For
same machine, tell it to listen to network address 127.0.0.1. For other
situations you can tell it to listen to the default network address, which
the control can determine.

When a connection request comes in on that port, the sock_Listener.OnAccept
event fires. Within that event give the handle of the request to the
sock_Reader.Accept method. You have now created a bi-directonal
communications link between the two applications. From now on, any data
coming in will fire the sock_Reader.OnRead event, and your data will be
available via the sock_Reader.Read method. Leave sock_Listener live,
listening for another connection request - in case you get disconnected.

For simplicity, launch the receiving application first so that the listening
socket is ready and waiting. If not there, the sending application will
either wait, or return a time-out error - your choice - how you set the
"blocking" property.

Sending Application:
The driving application only needs one socket, let's call it sock_Sender.
Set it up with its IP address as above. Call sock_Sender.Connect to make a
connection request to the other machine's IP address and port 3333. If you
chose a "blocking" connection, the call will not return until connected or
time-out. If you chose a non-blocking connection the call will return
immediately, and the sock_Sender.OnConnect event will fire when the remote
accepts the call. From then on, you can exchange messages via the socket's
..Read and .Write events. It is all event-driven. The socket connection will
exist until you close the applications or manually close the socket.

It's fast, it's light weight, it's event-driven so the code is simple, and
you aren't going to bog the machine down with polling, temporary files, etc.



"AG" wrote:

Split Access 2000 application.
As a user moves through records in an app on one machine I need to display
related records on a large screen.
The user's screen will be completely different that what is displayed on the
large screen, just related.
The large screen could be a second monitor on the same machine or on a
separate machine connected to the same LAN.

I am thinking two separate applications and would like suggestions on how
best to synchronize the two apps.
The time between the user moving to a new record, and the large screen
synchronizing must be a short as possible.
So far I have thought of two approches - updating a single record in a small
table in the back end, every time user moves to a new record and having the
big screen app poll that table once every second to trigger a requery.
Or something similar using a simple text file instead of a table in the back
end.

Any other suggestions?

--

AG
Email: discuss at adhdata dot com



.

Relevant Pages

  • [PATCH 0/5] [RFC] AF_RXRPC socket family implementation [try #3]
    ... These patches together supply secure client-side RxRPC connectivity as a Linux ... kernel socket family. ... presentation side is left to the client. ... Each connection goes to a particular "service". ...
    (Linux-Kernel)
  • [PATCH 0/5] [RFC] AF_RXRPC socket family implementation
    ... These patches together supply secure client-side RxRPC connectivity as a Linux ... Make it possible for the client socket to be used to go to more than one ... Each connection goes to a particular "service". ...
    (Linux-Kernel)
  • [PATCH 0/5] [RFC] AF_RXRPC socket family implementation [try #2]
    ... These patches together supply secure client-side RxRPC connectivity as a Linux ... Make it possible for the client socket to be used to go to more than one ... Each connection goes to a particular "service". ...
    (Linux-Kernel)
  • Re: Socket Exception
    ... In this case the server most likely rejected your ... connection. ... Each command is a new socket connection that is opened and closed ... /// Required designer variable. ...
    (microsoft.public.win32.programmer.networks)
  • Re: attn:MVPs
    ... winsock dll to the managed .net environment. ... I have an asynchronous TCP socket that listens for data from ... The Slave should not initiate any connection requests/ send other messages ... EXCEPT the acknowledgement for the incoming messages from master, ...
    (microsoft.public.dotnet.framework)
Loading