Probably a daft question, why don’t you call connect first? If that fails, no apps are listening, so switch that app to listen? (remembering to close the failed connect socket before you listen)
That is what I do actually now that you mention it. I don’t first call Listen. I call Connect and then if nothing is there I get a 103 error where I then close the socket and set it to listen.
OK. So maybe I was testing things backwards this morning with the example apps trying to listen first…
Ah ok, cool. I just mocked up a little test here and it works, but you have to close the socket after the connect fails or you get the problem you mention when you call the listen, nothing can connect back to it.
I think what might be happening is that I attempt to connect to the socket. During that time (and before the failure with error code raised) I am attempting to write to the socket. No, just tried that in the example apps. That doesn’t cause the issue.
I must be calling listen improperly at some point. I’ll have to see if I can track that down…Seems like once error code 105 gets thrown then the socket is hosed…
I can’t connect to feedback.app right now, but I remember there were some old bugs on Win32 builds where you had to call socket.Poll() a few times before the .connected value was correct. This could lead to it looking like a connection failed when it had actually succeded.
I’m running Win64 though so who knows.
Well, my customer just got back to me and it looks like the version using the Mutex is working great. I’ll have to track this down - why I am calling listen out of order…
[quote=450012:@Jon Ogden]I’m running Win64 though so who knows.
[/quote]
Win32 is Microsoft’s naming convention for the Windows API
Microsoft X86 and Microsoft x64 (Platforms) and Microsoft Win32 API for x86 and x64 builds
It’s a crazy world!!