Bug reports for HPComm 3.0r3

[Irl_W_Smith@xxxxxxxxxxxxxxxx]

These observations relate to the latest version (3.0r3) and also appear to occur
in the previous beta versions. The tested configuration was an HP48GX and a
Pentium II running Windows NT v 4.00.

1. WORKAROUND: The translation modes (MODE0, MODE1, MODE2, MODE3) are not
synchronized with the calculator settings automatically at startup. Go to
Calculator->Comm settings..., change to anything, hit OK, then change to what
you really want (see below) and hit OK again.

2.WORKAROUND:  In MODE0 and MODE1, HP filenames displayed may contain
nonprinting characters. In MODE2 and MODE3, file names displayed are translated
according to the mode setting (see User's Guide p 27-19 for a complete list;
generally special characters such as, e.g., greek mu, are converted into a group
of three characters starting with a backslash, in this case \Gm). Thus if you
have two files whose names are identical except for a non-printing character,
you will need to use MODE2 or MODE3 to tell them apart in the display. However,
you can't drag them in this mode because the name sent to the calculator
contains the translation strings and the HP doesn't recognize them. The body of
the file is transferred correctly, as far as I can tell, in any mode. If you
wish to be able to read or print it, though, you have to use MODE2 or MODE3.
In other words: if you have files with funny names containing funny characters
and you want to be able to read them after transmission to the PC, you have to
do the following:
--rename the files (or a copy) on the HP; the new name should contain only plain
ASCII characters.
--Use Mode 3 for the transfer to the PC.

On the other hand, for "general" use, i.e. just storing and re-transmitting
files on the PC, probably MODE1 is your best choice although file names require
some interpretation.

3. BUG: in Mode 0, the listing (in the PC window) of files (on the HP) is
randomly truncated; typically being short by one file. Probably HPComm doesn't
properly parse strings (the received directory listing) which end in
non-IBM-compatible end-of-line markers.

4. BUG: HPComm sets the HP directory to the one it most recently accessed (e.g.
by a Refresh operation) and then seems to assume the HP will stay there. If you
take the HP off-line to perform some manipulations, leaving it in a different
directlry, then go back on-line, HPComm is very confused about the directory
tree. Perhaps HPComm is not using full-path commands to the HP?

5. BUG: Under some conditions, such as dragging a file whose name has been
mistranslated (see note 2, above), HPComm becomes de-synchronized with the COM
port, leaving the PC in an endless loop (as seen by the Performance
monitor--100% CPU usage, or the Task Manager--one process, HPCOMM.exe, is using
up almost all the CPU time). The only way I know of to get out of this is to use
the Task Manager to End the Task (HPComm.exe). This violent maneuver seems (!)
to have no bad side effects.