I have two apps that I use to communicate but I don’t know which app starts first. So my socket is written so that the app can be either a listener or a connector.
Now, when I first attempt to use the socket I am getting an error code of 103 which is a name resolution error. So I think you get that when you try to connect to the socket but there is no listener. So then in the error method, I set the socket to listen mode.
Now I start my second app and I get the error code 103 again. I don’t think that should happen. Then I get an error code 105 (AddressInUse error) when I try to listen which would make sense…
It appears something is preventing my IPC file from being created. Windows has always been a little wonky for me with IPC. It used to work but I made some changes to my code and now it doesn’t. The exact same code runs perfectly in OS X. So I feel the basic methodology I am using is correct, but I am doing something wrong that is specific to Windows…
I’ll try that and I thought you might have been on to something there, however, there are no spaces in the path right now (there could be though as TMP is in the directory based on the user’s name). I’ll try it.
Well its what Xojo recommends to use for inter program communications. The problem with TCPSockets is that you cant have two apps that have grabbed the same port. So it wont work.
I just played with the IPCSocket example. I created a path with a space into it, but it works just fine with nativepath.
So the issue you report must be due to something else.
Could you try to run the example ? Just build one to run it, and run the second in the iDE. If you get the same error, I suspect it may have to do with an antivirus blocking the TCP port used by IPCSocket.
Well, I figured out my problem. And I’m not sure if it was Windows only or not.
My IPCSocket is part of a singleton class that handles both IPC and UDP communications. I had only recently made it into a singleton. When I first attempt to write to the socket I have a public method that creates the object, sets it up and starts the connection attempt. However, then in the write method, I was checking to see if the socket is connected and if not, then I call connect again. It was making this second connect call that mucks things up. From the first call to connect to the second, there was not enough time for the framework to make the connection and respond back that it was connected. Now that I am handling things correctly and not calling connect twice, it works just fine.
It’s possibly connected. However, I have my own Boolean variable for my parent class that gets set to true when the IPCSocket.Connected event fires. There is a finite amount of time between calling connect and getting the connection. Any time you call Connect with an IPCSocket and then call connect again (even after it’s connected), it messes things up and throws error number 103 (Name Resolution Error). Xojo should make it more robust so that if you call connect after the socket is connected, it just ignores it.
The path on Windows is just bogus, due there is no native IPC socket in Windows.
Xojo simply translate the path to a port number, due on Windows a loopback TCP connection is used.
[quote=387242:@Massimo Valle]The path on Windows is just bogus, due there is no native IPC socket in Windows.
Xojo simply translate the path to a port number, due on Windows a loopback TCP connection is used.
Hence you can use whatever you want as path.[/quote]
So Ive learned. But that was not my problem. The problem was calling the connect method on an IPCSocket that was already connected. I corrected that and things work great now.