Not sure about the rules regarding cross-posting, but I’m kinda stuck building an app until I can get past this, so the more eyes the merrier. If I’ve transgressed the unwritten (or written) law, please delete!
So… I can’t seem to get a Xojo TCPSocket working the way it does in VB.NET.
See: https://forum.xojo.com/58322-tcpsocket-listen-and-ports
Anyone good at both languages feel like having a crack at translating the relevant section?
Cross posting is fine - here 
You cant usually mention “other tools” in Xojo’s forums unless you’re trying to move code FROM some other tool TO Xojo so I’m almost surprised there are threads that havent been locked or deleted
Nothing wrong with cross-posting here.
It would be good netiquette to post the solution (if one is found) to all places though.
Whats not clear to me in that snippet is whether more than one connection can be handled at a time ?
It looks like when you press start, it waits for one client to connect, reads data until the client disconnects, then stops and you’d have to start it listening again manually ?
No draconian rules here. Cross-posting here fine, particularly whilst our community is small. Like @MarkusWinter says though, if you find the solution, could you post it here so everyone can benefit?
Moving on to the topic at hand - can you post the sample code to translate here?
Thanks, All.
I got the answer, and as usual, it had nothing to do with what I thought was the problem. It’s simply my inexperience with the “peculiarities” of Xojo. Makes it so much worse when I go back and forth to VB.NET.
Here’s what I wrote on the other forum:
So… In the end, nothing to do with Listen or Sockets. It threw me off at first that the returned port was the same as the listen port, because I foolishly thought that the Automatic connect and the Connect method would function the same, and that the random port would be returned upon connect. Kinda weird, but so’s a lot of stuff with Xojo, but anyway, barking up the wrong tree.
Came down to the Handshaking message in the Timer. This is what I had:
Dim HandShake As String = Chr(&hF0) + Chr(&h43) + Chr(&h10) + Chr(&h3E) + Chr(&h19) + Chr(&h7F) + Chr(&hF7)
TCPSocket1.Write(HandShake)
This is what Andrew suggested:
Dim HandShake As MemoryBlock = DecodeHex("F043103E197FF7")
TCPSocket1.Write(HandShake)
Andrew’s works, mine doesn’t. No idea why. TCPSocket.Write should be able to take a string just as easily as a MemoryBlock, but maybe not?
Bottom line is that TCPSocket.Listen doesn’t work as I would have expected, but neither does TCPSocket.Write.
And yes, the TCPSocket.Port will be the SAME as the listening port after connecting via an automatic connection after calling TCPSocket.Listen, but it will be different (a random port) after connecting via TCPSocket.Connect. I would think that’s non-intuitive, but what do I know?
I have to commend Andrew on introducing me to the DecodeHex function. I’m gonna use that sucker everywhere! Seems every week or two I learn a new trick from the old pros. I wish I could look at more experienced Xojo programmer’s code so I can see more of these shortcuts and tricks! There’s a lot.
BTW, Will DecodeHex ignore spaces? It sure would be nice to be able to write:
DecodeHex("F0 43 10 3E 19 7F F7")
Just for readability!
The Chr() method returns the character whose Unicode code point is passed, so your HandShake variable contains ðC>÷ which in hex is C3B0 4310 3E19 7FC3 B7. You can see this in the debugger if you put a breakpoint after your assignment to HandShake and then click the little pencil icon to its right. Then click the Binary tab:
Ah the difference between Chr() and ChrB()
ChrB() gives you a “character” that is THAT exact byte
Chr() gives you the character that is that code point which, up to 127, maps right onto ASCII characters. Beyond 127 thought you get the Unicode character at that code point whihc is NOT one specific byte but may in fact be a multi-byte run of bytes
Any thoughts on why the connected TCPSocket.Port is not the new, random port # when using TCPSocket.Listen?
(When connecting using TCPSocket.Connect, the port # is the new random port after the connection is complete)
On the listener side you ALWAYS get a connection on the port you listened on - not some random one
On the client side you can connect TO the listener on any port
The ONLY things that might affect this is if you are using a server socket to permit multiple simultaneous connections. In that case the server socket listens on the designated port and, when an incoming connection gets made, a new TCP connection is spawned and THAT new connection will be one some other unused port so the server socket can go back to listening on the original port number.
Ah. So it’s the direction of the connection! I see. Thanks, @npalardy.
Is there a way to report the remote port ala VB.NET?
RemoveAddress is all I know of but that does not include port number
Tested. Looks like it does. Very cool!
I rarely use DecodeHex 
I’d just go with
Dim HandShake As String = ChrB(&hF0) + ChrB(&h43) + ChrB(&h10) + ChrB(&h3E) + ChrB(&h19) + ChrB(&h7F) + ChrB(&hF7)
Chr is for when you want “textual data”
ChrB is for getting raw bytes
Oh for sure it has lots of uses
I just wouldnt use it for this purpose - thats all I meant
Why?
(Stupid 15 character minimum requirement filler!)
personal preference really
Lowered it to 5 