Interprocess communication (IPC) is the key word here.
GriffMG said:
There is no process to process communications provision
If you mean native functions and commands of VFP supporting IPC, then you're half ways right, but besides files used to communicate you can make use of BINDEVENT, of course. And send messages on the other end. Also, do it both ways around.
It also depends on whether you need to do this peer-to-peer on two different clients, so the IPC needs to make use of the network, or whether it's IPC between two processes like the already proposed idea of a foreground (Interactive with the GUI) and background (non-interactive, without GUI) process for doing things in parallel.
The mechanisms acting on the same computer are well known if you ever configured MSSQL communication protocols: Shared Memory is local, and pipes can be local or go through the network, even TCP/IP can go to localhost aka the same machine. For peer-to-peer communication (in detail ports/Winsock) you usually need to allow requests to go on routes usually only allowed for responses, so network admins won't like such solutions. The simplest way to communicate over the network still is via files on a share.
The other ingredient is that you want to not poll for signals but want a signal/flag to cause an event. And in that case, BINDEVENT is the simplest solution. You cannot only bind to the VFP class events, you can bind to Windows messages, and that does not only include all the messages coming from the OS but also user-defined messages.
If you look for IPC sessions at many VFP conferences all over the world you surely find some material to make use of.
I still wonder what is causing blocking when you make use of a timer. On one side I understand it's a bit cumbersome to need to poll for something to happen, like a file becoming existent, but let's say your timer runs 10 times a second, a FILE() or ADIR() check only takes split seconds and doesn't bog down your CPU and doesn't make your user interface unresponsive.
Especially since that waiting for a signal through a timer will happen in the background EXE, not the EXE that has the user interface, that should be the process that causes the other to act, not act itself, so it'll not be blocking the UI, it'll only write the file or add a record to a DBF to trigger the other process to do whatever in a non-blocking way.
Well, and a second EXE means another process. Whatever another process does is not blocking, unless you actually bog down CPU/RAM/network with whatever you do so other processes are influenced. Usually not, even way back when we only had single core CPUs Windows already managed to run tens if not hundreds of processes in parallel by giving each process time slices on the CPU, that's automatic and still automatic in the era of multi-core CPUs, there's nothing to do. So that should answer the main question you had:
dkean4 said:
Can 2 independent apps be running concurrently while one passes occasional flags?
Yes.
Unless you mean APP as in VFP APP file that you run by DO. That's not starting a new process, that runs within the same process, not in parallel. Even DOing an EXE doesn't start a new process, by the way, so the problem is DO, not the file extension.
And all that said, now it will depend on the nature of the communication you want to establish between the two processes, whether you actually need IPC or not. Not only the timer polling for a file is one solution to that if you only want to start something that runs in parallel as long as it needs without blocking your user interface then all you need to do is RUN another EXE using the /N option so it does not wait for the new process to finish. Well, take a look into the help of RUN for the /N flag. Other options are CreateProcess Windows API, besides others in the same family of process-starting API functions. ShellExecute is another possibility.
There are naturally some gotchas. A new process is a new process, it needs all info passed in via parameters or externally, for example by files. But then you have a database system, you can "pass" on a whole database. Just don't program the background EXE to know any of the properties/states of the main interface EXE, of course, not even the default path. It's a new process and you need to provide anything that the new process needs to know to do the background task, ideally completely independent from whatever the main process continues to do.
Coming back to the point where I said Griff is halfway right. On one side Nigel already talked about DDE, which is part of the VFP language on both ends of sender and receiver, while BINDEVENTS only is on the receiving side. But you only need the SendMessage API function declaration to be able to send out those messages another process waits for via its BINDEVENT. It doesn't involve actively waiting and polling for signals, once you make the BINDEVENT binding you wait for any instance of a specific message number, without a timer becoming active every interval. If you send a message the response on the other side is immediate and can do whatever in the other process without interfering with the responsiveness of the UI of the main EXE process, which sent that message, i.e. sending a message is not waiting for a response.
If you bog down the network or CPU, RAM or I/O, that's another story, but if whatever you'll do in parallel is that resource hungry you better implement it on some server and not just as a background process.
If another process doesn't suffice, you can run as many parallel processes as you like, the natural limit is the number of physical or virtual cores that actually can run in parallel and if any resource is needed exclusively multiple processes also can't accelerate things, obviously, but it would actually be hard to bog down the process that keeps being the UI for the user. It's really parallel running code.
And signaling to finish or returning a result? That return path has multiple options, too, you can again use the Windows message system or any of the IPC mechanisms.
One thing is sure, just like with DDE or files, you of course have to know things in advance. The DDE topic that is used, the port number, the windows message number, the name of a named pipe the file name, there is no IPC only programmed on one side that needs no control over the code of the other side, the minimal requirement is that the other process already uses some of the IPC mechanisms, i.e. it already generally listens for input on a StdIn pipe. You can't inject, establish the receiving end and force another process to listen on this channel, so it's always a two-sided implementation, even with the simplest of shoot-and-forget with RUN /N the called EXE has to expect the input parameters/files it needs to do whatever it should do. So, even one-way communication needs a "contract" to agree on. The only way the other EXE doesn't need to know anything in advance is when you'd write the code and BUILD and then RUN it, but that's surely a recipe to trigger an antivirus system. A milder variant would be EXECSCRIPT, but that does run in the same process again.
Chriss
