Patrick, Again, many thanks. I did finally get a TCP/IP client to work with Skychart, but I don't like what I needed to do to make it work.
I downloaded a TCP Viewer from Westbrook Software (http://www.westbrooksoftware.com/default.aspx ). This is an excellent tool that shows all of the data going back and forth, I highly recommend it for anyone trying to debug a TCP/IP connection. The problem with getting to the "connect" state was because the two responses from the server ("connecting" and "connected") were so close together, right on top of each other. Apparently Windows was losing the second message! So I found that by putting several "DoEvents()" statements following the Winsock.Connect, this would slow things down enough for Windows to see the second message. However, that is a very "messy" programming technique, and I do not like using it. Since it depends on a "race condition" (which order independent software tasks process things), it is likely to fail in some systems. This illustrates how developing real-time multi-tasking code is very different from developing an application. The application will work when the logic is correct, while the real-time code will not work until the logic is correct, and the real-time aspects of the processing are properly coordinated, too. Then the Winsock SendData method didn't work, either. Ultimately, it turned out that the SendData method does not send the data when you tell it to, but instead buffers it up until you exit the function where it is sent! And since I was closing the connection after all the data had been "sent" (or so I thought), no data was getting out because the connection was already closed before Winsock tried to un-buffer it! Again, correct logic but wrong real-time implementation. I very much appreciate your suggestion to use the Command Line options (as RTGUI does for Ver. 2.76, this works well). The only reason I began to work on the TCP interface was because the documentation did not show those commands as available. Apparently this has just been added to the newest Beta. I will update my Beta, then try an implementation using Command Line options. Not only does this greatly simplify the code, but it removes all dependencies on timers, real-time race conditions, etc. Plus, it is faster. Instead of waiting for Skychart to initialize its TCP client and draw its first map, the options on the Command Line will produce the first map, not the second. Again, many thanks. I would suggest to other programmers to only use the TCP/IP interface if you really need to get something from Skychart at run-time, otherwise it's quite complex. Robert Sheaffer --- In [email protected], Patrick Chevalley <p...@...> wrote: > > Hi Robert, > > The server code I use is here: > http://svn.origo.ethz.ch/wsvn/skychart/trunk/skychart/cu_tcpserver.pas > > One thread (TTCPDaemon) is waiting for a new connection, then it start a > client thread (TTCPThrd) to handle the connection. The program is configured > to have up to 10 simultaneous client, each connected to its own chart. > You can see connected client from the menu View / Server information. But > this not write anything to the trace file to avoid any conflict due to the > multi-thread nature of the process. > > I not have VB6 but I try to make a vbs client. Unfortunately there is no > winsock object available for scripting on a basic Windows installation. > So I use a third party library to make this working client: > http://svn.origo.ethz.ch/wsvn/skychart/trunk/skychart/sample_client/script/vbclient.vbs > > Also since this week snapshot you can send command to a running instance > using command line options. This can be an alternative if you don't need > interaction with Skychart but just send pointing instruction. > See this example: > http://svn.origo.ethz.ch/wsvn/skychart/trunk/skychart/sample_client/script/client1.cmd > Documentation of the available options: > http://www.ap-i.net/skychart/en/documentation/line_commands > > Regards, > > Patrick >
