Bug storm

[Irl_W_Smith@xxxxxxxxxxxxxxxx]

As of shortly after I installed the limited-distribution version (from James) of
HPComm3.0r3bx, a number of bugs had been fixed, including "Truncation of
directory display in Mode 0". The program worked quite reliably at 9600 baud and
the only remaining previously-reported bug was the "crash on mu" bug, described
below.
When I installed the latest beta, the "Truncation on Directory Display in Mode
0" bug was back! It was also back in the version which had worked before! In
other words, something seems to have changed on my PC, and I don't know what.

In any case, I now see the following bugs:

1. Directory truncation in mode 0.
Note: if you have a correct display of the directory contents showing in the
lower righthand pane, then change to Mode 0, you must hit Refresh to see the
error appear, namely, an HP48 variable (the first one on the HP48 menu bar) is
missing from the list displayed on the PC.

2. Crash on mu.
Create a directory "TMP" containing a variable named "mu" where by "mu" I mean
the Greek character (alpha right-shift N on HP048).
Go to this directory.
Drag the variable "mu" to the PC.
Result: "File transfer" dialog comes up, all boxes empty except "packet", which
says "waiting". The HP48 beeps and displays "Illegal packet" repeatedly at
intervals of a few seconds. Only way to get out seems to be to hit "cancel" on
PC. PC becomes bogged down; Task manager shows HPComm is using 98% of CPU time.
Exit HPComm and process is still running, using 98% of the CPU, and can only be
terminated using Task Manager.

3. Refresh self-inconsistencies.
I see that upon Refresh you collapse the directory tree in lower left panel if
several branches were open and displayed, suggesting to user that these are no
longer cached. However, they ARE still cached (folder icons shown without
question mark) and haven't been refreshed.
Do the following:
Display contents of directory DIRA, which contains variable X.
Display contents of some other directory, say, DIRB.
*On HP-48, go off-line, go to DIRA, delete X, go back to DIRB, go on-line.
(see item 4 below for "*")
On PC, hit refresh (DIRB still displayed)
Click on DIRA, whose icon is a regular folder, NOT one with a question mark.
Its contents are displayed as before, including the now nonexistent variable X.
Drag X to PC, and "undefined name" shows on HP-48.
While this bug doesn't cause a crash, it is certainly confusing to the user.
One possible fix, which I have no idea if it's practical or excessively hard to
code: any time you refresh, collapse the whole tree except for the leaf
displayed and the path to it, refresh only the resulting visible display (both
panels), i.e. go down the tree from HOME to the displayed (lower-right-hand
panel) leaf, refreshing only the part of the tree displayed (not any other
previously cached branches and leaves), including finally the leaf. Forget the
other parts of the tree. Alternatively, you could refresh anything you had
cached, which might be too time consuming; but at least if you show it without a
question mark I would think it needs to be refreshed--including internal
subfolders you would show with no question mark if the user navigates to them.

4. Off-line directory switch confuses PC.
If in example 3 at *, you don't change back to DIRB, but instead go to DIRC, the
contents of DIRC are displayed as being in the DIRB. Again, no crash but
confusing.

5."Connection failed" won't dismiss.
My system works OK at 4800 but not at 9600 (although it used to!). I suspect
it's close to working, which is probably relevant here--some data gets through
but not all. If I set everything at 9600, and try to connect, the "Connection
failed" dialog comes up (after some signs of activity on the HP48--some "Packet
received" messages) and there is no way to cancel the process to allow me to
change things to 4800. Hit "OK" and it tries again. Hit the "close window" (X in
upper right on window title bar) button and the same thing as OK. Need to add a
"OK, give up already" button, or make the "close window" button function as a
cancel, not OK. A workaround I found is to take the HP48 offline. Then the OK
button results in PC giving up, which is what I'm looking for, not endless
retries. Note that this is very different from what happens if the baud rates
are set differently on PC and HP; in that case there is an immediate "connection
failed" dialog which dismisses on OK and doesn't keep trying.

6. Mode inconsistency. No matter what mode (translation and checksum) the HP48
is in upon HPComm startup, HPComm displays Mode 0 and a blank entry for
checksum. However, the transfers still work! Apparently HPComm can figure out
what mode the calculator is using. Even if I change the checksum mode, transfers
work OK. I don't see how this is possible... However, it would still be nice if
the translation mode and the checksum method displayed in the Calculator
Communications Settings dialog were those in use. Or, if it is your intent to
use the dialog only to CHANGE the settings from those already sensed (somehow),
maybe leaving BOTH boxes blank would give the user a valuable clue.

--Irl
P.S. If you have any thoughts as to why some of these suddenly reappeared (e.g.,
no. 1, above), I'm all ears...uh, eyes, this being email.... I have NOT gotten
any viruses recently. Any important DLL's I should check version numbers of?