Patrick,
Thank you very much for your reply. I know that the problem is not simply a
lack of time for Skychart to initialize. I have paused my code for ten seconds
or more to let Skychart run, it doesn't change anything. By the way, on my
(very average) 2 Ghz system running Windows XP, it takes 900ms from "start
trace" to "listen on port 3292". It takes about another 500ms to finish up
drawing its initial chart, to get to "release refresh lock," when it is
presumably ready to start drawing a different chart. That's a total of 1.4
seconds.
I do not see anything in the trace to indicate that a TCP connection has been
requested. I had expected to see something like "TCP Connection Request",
"Entering State 1", "Entering State 2", etc. Are messages like that included in
the trace? If so, I am not seeing them. Is it possible to see the code that
Skychart uses to answer TCP connection requests? Perhaps I could see from that
code what it is waiting on to go into "Connected" state (7) from the
"Connecting" state (6).
Don't worry, I won't let my receive buffer fill up! I expect the connection to
be very brief, anyway: just long enough to send coordinates to skychart, and
tell it to "redraw".
Robert
--- In [email protected], Patrick Chevalley <p...@...> wrote:
>
> Hi Robert,
>
> I can unfortunately not help with VB6 specific, maybe other here have
> experience with that.
> There is example client with Java, Perl and Pascal with the source code (
> http://svn.origo.ethz.ch/wsvn/skychart/trunk/skychart/sample_client/ ) but
> all require that skychart is started first.
>
> But what I can say from you code is the time let to skychart.exe to start is
> probably too short, try to increase the sleep time to five second or start
> skychart manually before your test program.
>
> You can know the socket is ready on the skychart side by monitoring the file
> C:\Users\[username]\AppData\Local\Skychart\cdc_trace.txt . It must contain
> "Listen on port: 3292" (warning: language specific).
>
> Even if you not use the data send by skychart you must periodically read the
> socket (with zero timeout) to avoid problem with a full buffer.
>
> Patrick
>
