Re: Bug reports for HPComm 3.0r3

["James" <james@xxxxxxxxxxxxxxx>]

Dear Irl

About funny file-names:

It always was a big pain in my ass how the calc transmits the content of a 
directory to the PC. In my point of view it's too pedantic that the calc 
translates the filenames according to the translation mode that is set on the 
calc.
The problem is that the PC can't handle these special characters within a file 
name (try creating file which is called p/->s ...). We have 4 (!) translation 
modes which means a file name can have 4 different names (kind of). At the 
current state we try to filter these funny names and send a program to the calc 
which temporary renames the file on the calc so that they can be transmitted to 
the PC and renames them back after they are transmitted. I admit, a poor 
solution, but maybe the only one...
But there is absolutely no chance to transfer the file back to the calc so that 
it has the same name again (which the funny character)!!!!! No chance.

Everyone that  has ideas how to workaround this problem is welcome to give us 
some hints!

> 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.

I will check if the translation mode is always set correctly...

> 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.

Hm. Could you please give us an example of a directory (with the names) where 
this happens? We had similar bug-reports about similar things...

> 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?

First of all: You can't use full-path names with kermit. You always have to 
change to the dir where you want to perform an operation. Because the 
calculator always transmits the stack after such an operation (please don't ask 
me why...!?!?!) it costs a lot of time to change the directory on the calc.
Before every file/directory operation, HPComm checks if it is in the directory 
it last read in (this means where the calc is) and where the user browses (this 
is which directory is shown on the PC). If it's not the same, HPComm changes to 
the desired directory.
This means NOT that you can go "offline" and change the directory structure. 
HPComm relies on what it read in. It caches the already read directories. We 
can't afford to read in the directory structure before every operation you make 
in HPComm. It would just take too much time.
This means: You can change your directory when you go offline, but you can't 
change the structure/content of the already read directories.

> 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.

This is bad and should not happen :-(
When you give us the exact circumstances about when and where it happens we can 
take a look.

Thanx for your efford to use HPComm and detect bugs :-) We really appreciate 
your feedback.

Regards

James