'Pushing' Status of Access Application to another Access App

[Alex Linthicum]

Hi,

I've created two access Apps. App A calls App B to perform some
lengthy and computational processes. Currently I'm using the
acSysCmdSetStatus cmd to update the status of App B, and I'm wondering
if there's a way to 'push' the status of B to A when the status
changes.

I'm thinking I might be able to achieve the same result if I can open
both apps in the same application object but hide B when it is
performing its calculations; then when B updates the application
status, it will be visible from A. I might also have to use the
DoEvents() command.
Has anyone done this before?

Any knowledge would be appreciated.

[Scott Simonson]

Just a quick thought, why not have yet another mdb "C" that has a table that
"B" populates and indicates its status changes. This way any app can look at
"C" and see where anything is going. You could even have a separate history
table to review previous jobs.

Just a thought...

Scott

"Alex Linthicum" <as*****@gmail.com> wrote in message
news:11********************@z14g2000cwz.googlegrou ps.com...

Hi,

I've created two access Apps. App A calls App B to perform some
lengthy and computational processes. Currently I'm using the
acSysCmdSetStatus cmd to update the status of App B, and I'm wondering
if there's a way to 'push' the status of B to A when the status
changes.

I'm thinking I might be able to achieve the same result if I can open
both apps in the same application object but hide B when it is
performing its calculations; then when B updates the application
status, it will be visible from A. I might also have to use the
DoEvents() command.
Has anyone done this before?

Any knowledge would be appreciated.

[(Pete Cresswell)]

RE/

I'm wondering
if there's a way to 'push' the status of B to A when the status
changes.

I did it a few years back using COM, but can't regurgetate the specifics beyond
that it was straightforward (i.e. no tricks...it just did what was needed...)
but not trivial (i.e. I had to create a number of objects).

A backdoor method would be to use .txt files as semaphores. Have the Receiving
app continually check for a .txt file named something like "Flag.txt" and the
sending app create same when it wants to push.

The receiving app would have a timer look checking for the file. Whenever it
finds it, it would take the desire action (and if more info was needed, extract
same from either file's name or contents) and then either rename or delete the
file.
--
PeteCresswell

[Tom Warren]

I can't tell from your posting if you're trying to have one "master"
app control multiple "slave" apps on the SAME computer or, if you're
trying to have one app on a "master" computer control multiple "slave"
computers?

In the first case, you might what to look into Office-Automation. It's
well documented in help, and is pretty easy.

I do a lot of work with the second case, (Tiger, Census, 100's of
millions of phonebook entries) basically distributive processing of
large database processes across networks. This is trickier, in general
the "master" computer launches "slave" computers on a network to
execute processes. For this one, look into the /cmd command line
switch and the Command function to return /cmd's argument. The "slave"
databases link to RunQ and Status tables in the "master" database for
communications. The "master" database monitors the Status table for
communications form the "slaves" and the "slave" databases monitor the
RunQ table for communications form the "master".

Have fun.
Tom