Telnet component design issue

  • Thread starter Thread starter ozbear
  • Start date Start date
O

ozbear

I have been writing a Telnet client control with various terminal type
emulations available such as ANSI, VT100, Linux/XTERM, etc. While my
control works, the actual console portion of it derives from the old
workhorse richeditbox.

Richedit supplies useful functionality such as a cursor, ability to
copy the text to the clipboard, colours/highlighting and so forth,
but is relatively clumsy when updating when new information is sent
from the Telnet host.
For example, when connected to a Linux host, the "aptitude" program
sends back an extremely "busy" panel of information. There are
many, many, cursor positioning and highlighting commands in the
datastream and the information to be displayed is not in a simple
top-to-bottom sequence.
Since the ANSI highlighting commands only specify the current high-
light to be applied from the current cursor position on, you cannot
really start doing highlighting via the various richtextbox
Selectionxxxx method calls since you do not yet know how long the
selection is until another highlighting sequence arrives.

I have solved that issue by maintaining a backing array of row x
columns characters and row x columns attributes (underline,
reverse video, forecolor, backcolor, "blink"). As characters arrive
from the host, the backing array is updated with the display data and
the associated highlighting attributes. When required, the backing
array is transferred to the richtextbox's Text property and then I
run through the attributes deriving a "map" of character positions,
attributes to be applied, and lengths derived from when the attribute
at position r/c differs from r'/c'. The Selection length, start,
colours, fond attributes (unlerline, etc) are then applied.
This minimises the number of Selectxxxx calls and the associated
Windows messaging overheads, flicker, etc.

As I said, this all works, but I am interested in opinions as to
whether this was the best approach. In particular, whether the
richtextbox was the best base class. If I didn't need the abilty to
copy text from the screen via mouse select+control-C, as you would do
in, say, Notepad, I could have just used a Panel with DrawString
outputing the characters + highlights.

For copyings it seems I am stuck with the edit-control classes and of
them only richtextbox has the colour and highlighting functionality.

Does anyone have another suggest on the whole approach?

Regards, Oz
 
Hi,

(IMO)

What you have done is the only approach that I can think of. Certainly,
there might be differences in actual implementation, but at the end of the
day, the results will be similar. If you were writing this in C++ and MFC,
for example, the bookkeeping would be on the same scale, and you'd have even
more work to do with with the actual data display.

BTW, what you've undertaken is a really big project. What are you going to
do when it is complete?

Dick

--
Richard Grier, MVP
Hard & Software
Author of Visual Basic Programmer's Guide to Serial Communications, Fourth
Edition,
ISBN 1-890422-28-2 (391 pages, includes CD-ROM). July 2004, Revised March
2006.
See www.hardandsoftware.net for details and contact information.
 
Hi,

(IMO)

What you have done is the only approach that I can think of. Certainly,
there might be differences in actual implementation, but at the end of the
day, the results will be similar. If you were writing this in C++ and MFC,
for example, the bookkeeping would be on the same scale, and you'd have even
more work to do with with the actual data display.

BTW, what you've undertaken is a really big project. What are you going to
do when it is complete?

Dick

Dick,
Thank you for your reply. I was hoping I had overlooked some
opportunity for using some Windows functionality that would allow
me to poke characters and/or highlighting in either a rich text
box or other control without having to do all the Selectxxxx
method calls with their attendant Windows messaging overheads.

The actual Telnet component is a user control. The user control
hosts my Telnet socket implementation that looks after all the
Telnet protocol machinery (e.g., all the IAC requests and responses)
as well as a tool strip with a connect button, tool strip menu
for console-type selection, and setting properties for host name
or ip address and port number, if other than 23, local/remote
echo, and so forth.

The user control also hosts the actual richtext-derived console
which is constructed dynamically. It is essentially finished
except for implementing some of the escape codes peculiar to
some terminal types but that is really just a matter of filling
in some unimplemented switch() cases. The bulk of the work was
in getting the backing array and highlight maps constructed and
applied at the correct times. Fortunately, via inheritence,
the Linux console could inherit a lot of its functionality from
the VT100 console which in turn derived from ANSI console (where
most of the highlighting machinery lives), which derives from
BaseConsole. There is also a DumbConsole that derives directly
from BaseConsole which pretty must just supplies a line-at-a-
time console much like a "printer", with no highlighting.

Implementing a new terminal type, say a VT320, is just a
matter of deriving from an appropriate console type (or
even BaseConsole if it is a really weird one), and implementing
its escape codes to manipulate the backing store object.

The OnKeyxxxx methods may also have to be overridden to send
sequences peculiar to a given terminal type for, say,
function/arrow keys.

I had need of a Telnet gizmo that could talk to a variety of
host types as well as prividing a programmatic interface to
supplement user input.

Oz
 
Back
Top