Error #75 at Open {file} For Input As #1 (need 2 progs on same PC to communicate)

[madscijr]

They set the flag for who has control, and skip doing anything unless they have control...  Then when they're finished writing, they set the flag so the other program now has control to read.   

I mean you didn't really solve the underlying problem, you simply avoided the race by adding a _Delay .1

That said, one-way commutation with three states like you're doing has some potential. I'd still be concerned about caching, especially on Linux and Mac OS where we make use of the C++ file streams, but overall I think it's ok.

You can skip that delay completely and the flag system will still work.  The programs just take turns working with the file.

Program 1 starts up.  Creates file.  Sets flag for "In use."  Writes to file.
Program 2 starts up.  File exists.  Checks flag.  It's in use... does nothing.
Program 1 finishes writing.  Sets flag for "Hey you, read this!"...  It now enters standby mode.
Program 2 sees flag.  Reads file..
Program 1...  File still flagged for program 2 use... wait...
Program 2 finishes reading file.   Now writes whatever data it needs to send back.
Program 1... File still flagged for program 2 use... wait....
Program 2 finishes writing to file.  Now sets flag to "Hey, Program 1, it's your turn!"
Program 1... Reads flag...  Takes control...

BINARY lets you read and write at the same time.  As long as the first byte in the file is set, you can toggle that back and forth to pass control to whichever program gets to use the file at any given time.  

May wear your drive out toggling that one byte over and over and over again, but it's quite doable.

Even with caching, it wouldn't matter, as the control remains with the other program until that cache catches up and updates...  though if your cache doesn't push to file for a while, you may end up with both program just being locked in a waiting state until that write finally occurs. 

---

And with that said, I still think the easiest way to do things would be to just OPEN "localhost" for TCP/IP and PUT/GET info back and forth like that between the two programs. 

Yikes... That all seems a little too "bare metal" for comfort, lol. 
I'm sure it could work, the TCP/IP method just seems a lot cleaner, nice and simple! 

What about shared variables in memory? One program could use TCP/IP to pass a pointer to the address of the variable to the other EXE, and as long as both of them always write a fixed anount of bytes to it, they could swap values back and forth. It's also kind of low level, I'm just curious if it would perform any faster than pure TCP/IP...