I've finally figured out that I _can_ use the RecvTerminated() function once I know what kind of "prompt" to expect as a result of my last command string sent.
My problem was that I was relying on that function during the "interrogation" phase of my startup, as I tried to figure out what state the remote system was in. And that was never going to work, due to the number of states (and therefore the strings returned with different endings). I *could* have assumed (and demanded) that the remote system was running my remote server software (which is what I'm using to find and transfer files within this application), but since I want this software to be useful to other people, I have to also test for different prompt strings. My remote system runs TurboDOS, which has a prompt like 0A}_ , but CP/M uses the A>_ type of prompt, and my server software's prompt (TR:>_)is only valid if there is no transfer request pending, in which case the end of the string will look like [1234] (if we're waiting for a confirmation to continue sending the data packet), or Retry [Y/n]_ if the last packet didn't get confirmed. That's all easy to do in person, but if I connect to the remote system after it was disconnected in the middle of a transfer, I have to be able to figure that out too. That's what was doing my head in. So I've learned to do my figuring-out using the single-char receive routines, then once I know what the remote system is doing, I can then start sending commands so I can ensure I'll get a particular prompt string, which will then be the terminating sequence of the data. Easy Peasy. Right? It took me over a day to figure that out. And I still have to figure out how to handle the multiple lines received before the terminating string, and strip them out into separate string entities, and so on and so forth. At least, defining the problem clearly made it a bit easier to figure out why I can't seem to identify and then handle incoming data properly initially. I must admit, it's really interesting to write an application that works from the user's perspective, instead of the developer's perspective. When you _don't_ know what the remote system is doing when you connect, it can be extraordinarily difficult to figure things out. And to remove all assumptions is an order of magnitude more difficult again! When (not if) I get things working, I'll post some details to possibly help anyone else trying to do a similar thing. The synapse project has such a lot of skills in the background, but we just don't seem to have time to clarify and explain what worked and what didn't (and why). Been there, done that, mea culpa. -PCPete ------------------------------------------------------------------------------ Register Now for Creativity and Technology (CaT), June 3rd, NYC. CaT is a gathering of tech-side developers & brand creativity professionals. Meet the minds behind Google Creative Lab, Visual Complexity, Processing, & iPhoneDevCamp asthey present alongside digital heavyweights like Barbarian Group, R/GA, & Big Spaceship. http://www.creativitycat.com _______________________________________________ synalist-public mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/synalist-public
