Re: Client/Server sockets with TK on Win32

With your code unchanged, the client connects to the server just fine (Vista-64/AS5.10.1-64).

After that, not much seems to happen, but with two different subs attached to the readable event, and an absence of error checks that doesn't surprise me.

I'm also a bit surprised that the code works as-is on *nix.

I'd also have expected you to have to set the sockets non-blocking for the fileevent stuff to work.

With the rise and rise of 'Social' network sites: 'Computers are making people easier to use everyday'

Examine what is said, not who speaks -- Silence betokens consent -- Love the truth but pardon error.

"Science is about questioning the status quo. Questioning authority".

In the absence of evidence, opinion is indistinguishable from prejudice.

The start of some sanity?

Comment on Re: Client/Server sockets with TK on Win32

Replies are listed 'Best First'.
Re^2: Client/Server sockets with TK on Win32 by Anonymous Monk on Apr 16, 2012 at 14:09 UTC
there are two text boxes at the bottom of each window taking an input. This text input "should" be passed from client/server	[reply]
Re^3: Client/Server sockets with TK on Win32 by BrowserUk (Patriarch) on Apr 16, 2012 at 14:26 UTC
there are two text boxes at the bottom of each window taking an input. This text input "should" be passed from client/server I appreciate that. All I said was that the connection is established. In contradiction to the claim in the OP -- "however when I try and port over to windows I just can't get the client to connect to server. " -- the the client does connect to the server. However, beyond that I don't know enough about Tk fileevents to debug the rest of the code. I can see from reading the POD that it says "However, there may be at most one readable and one writable handler for a file at a given time in a given interpreter. If fileevent is called when the specified handler already exists in the invoking interpreter, the new callback replaces the old one." -- which means that even if teh code "works on Linux", it is broken as posted. The POD also says: "Event-driven I/O works best for filehandles that have been placed into nonblocking mode. In blocking mode, a print command may block if you give it more data than the underlying file or device can accept, and a <>, sysread or read command will block if you attempt to read more data than is ready; no events will be processed while the commands block. In nonblocking mode print, <>, sysread and read never block. See the documentation for the individual commands for information on how they handle blocking and nonblocking filehandles." -- which suggests that it probably isn't "working on Linux" as posted. The POD also says: "BUGS On windows platforms fileevent is limited in the types of filehandles that behave correctly. Making filefhandles non-blocking is only implemented on a subset of UNIX platforms (see the Tk::IO manpage). -- which further suggests that the code as posted is broken. With the rise and rise of 'Social' network sites: 'Computers are making people easier to use everyday' Examine what is said, not who speaks -- Silence betokens consent -- Love the truth but pardon error. "Science is about questioning the status quo. Questioning authority". In the absence of evidence, opinion is indistinguishable from prejudice. The start of some sanity?	[reply]