You haven't explained how you got into your current situation so your
reasons may be eminently valid for you but might not hold water with
the rest of us.
The answers/observations here don't directly answer your post. I
don't really know that it is possible to do as you ask. I suspect
that it is with sufficient research and endeavor that will probably
take you into the realm of Windows API programming.. I recommend
against taking that path and suggest that you consider what follows.
If both Access applications have to be running on the same PC (you
didn't say 'server') and they absolutely, positively must communicate
with each other then implicitly they are simply parts of a single
application. Unless there are overwhelming constraints to the
contrary (turf wars and political reasons are the usual reasons that
trump followed weakly by "well we can't spend the time and money to do
it *right* now) then the two applications should be re-written as a
single application. Then when the event occurs that would previously
have been cause for communication simply take the appropriate action.
All done and in a simpler and more reliable way.
If the above isn't persuasive then I suggest that you fall back on an
old tried and true method of *asynchronous* communication between
communicating applications that worked well in the Street (One Way)
mode of interacting with mainframes: The sending application writes
or appends a text file with a given pathname. The receiving
application checks for the existence of that file from time to time.
If the file is found, it is read and processed *and deleted*, ready
for the next write from the sender.
If the sender cares, it can detect the absence of the file and
interpret that absence to mean that the last sent message was
received. Low level File I/O will create a file opened for Append if
it doesn't already exist. Otherwise, it simply appends new
information to the end of the file.
HTH
