How data are sent
The Telnet protocol offers a wide variety of control sequences for cursor positioning. However, when you look at a telnet screen in a regular telnet client, you cannot be sure in which order the displayed data are sent. Many users think of this as a stream
with consecutive characters from the top left corner to the bottom right corner: Unfortunately this is wrong in many cases.
Take a look at our screen:
01 Dummy screen
02 Line 2
03 Line 3
Example 1: Simple screenshot
There are several ways how this information can come on this screen. For instance it is possible that the server firstly sends a cursor positioning command as "Cursor Line 4/Col1", afterwards sends "Enter:", followed by "Cursor Line
1/Col1" and so on. Of course, it is also possible that the data flow really starts in the top left corner and goes step-by-step to the last line. Without further information you cannot tell. For batch processing it is very important to understand this
fact because you usually send a response based on information you receive (see
examples). The order may be crucial.
Problem 1: Virtual screen size
Let's go back to Example 1 and assume that the server sends a footer line too. Furthermore we are not lucky now and the server sends the footer first:"Cursor Line 10/Col1", "I am the footer". With a screen size of 4 lines the result
looks as follows:
10 I am the footer
Example 2: Screen scrolls down
Since the virtual screen provides scrolling, it sets the visible area after the first cursor command to the last 4 lines. Lines 1-6 are invisible and ignored, a behaviour which is very similar to a command shell. But what does this mean for your batch program?
When you wait for "Enter:" you will most likely wait until the timeout and your program will fail.
Luckily the solution is easy: Increase the screen size and try again.
Problem 2: Response send too early
It even comes worse: The data are send in chunks. As in Example 1 we assume the server sends "Cursor Line 4/Col1" and "Enter:" as one chunk. Your program waits for "Enter:" and immediately sends a response after finding
it. The server side is still busy by sending other data and it might be that the response "gets lost" on the server. Users told me about this phenomenon which seems to happen when you run not a shell but an arbitrary program on server side.
Solution: Try to wait before sending the response, use Wait(int seconds)
Problem 3: Screens being always updated
Sometimes a Telnet server continues to refresh a screen. My router does this, it has a page where one can see the traffic send to the internet. Therefor it continues to send something like "Cursor Line 2/Col1", "10k", "Cursor Line
2/Col1", "12k" ....
Keep in mind this may happen, especially when having problems with the method WaitForChangedScreen(int timeoutSeconds).
Problem 4: Trouble with WaitForChangedScreen(int)
The method is quite easy to use, nevertheless it is important to understand how it works. The virtual screen features a flag updated when the screen changes. This flag is always being reset when the method Hardcopy() is performed.
WaitForChangedScreen(int)also resets this flag.
As a result of this it is important to understand that
WaitForChangedScreen(int) detects all changes after the method has been called, NOT prior this point.
WaitForChangedScreen(0) can be used to reset the flag.
tn.SendResponse("dir", true); // send Telnet
Very theoretically thinking it could happen that a response is sent after SendResponse(..) was called and before
WaitForChangedScreen() can detect it. However, this is very unlikely.
Question: On my system no .exe but a .dll will be compiled, what do I wrong?
Answer: I can tell for Visual Studio -> Make sure the project is set to "Console Application"
Question: The WaitForString(..) method times out!
Answer: Use the Hardcopy() method to look at your screen buffer and compare this to the scenarios outlined in
Question: The WaitForString(..) method does not find a string, although I know the string is sent!
Answer: Check the different overloaded methods to use case-sensitive / case-insensitive search as appropriate. Also check your virtual screen is big enough to capture all the output (the screen emulates scrolling if the output exceed the number
of lines). Use the Hardcopy() method for debugging. Further information can be found in
Question: My program works if I run it in the debugger, but fails running without!
Answer: Most likely I timing problem, read the information in
Question: How can I send function keys?
Answer: Find the codes
here. Or use the method Terminal:SendResponseFunctionKey