Bug squashing: Day #1

Hi,

We'll, 

I think I have managed to squash two bugs, hopefully without creating 4
bugs to replace them. ;-)

The first was the problem where hitting enter (or another aid generating
key) two or more times in quick succession would cause an assertion
complaining about trying to send fields when we weren't in a read state.

If you hit the aid generating key too fast, the emulator would read the
keystroke before it had obtained the read command from the network.  If
you were to key more slowly, the read command would already have been
retrieved and everything worked fine.

I have changed the behavior of the emulator, so that if an aid key is
pressed in a non-read state, we save it until later when the read command
is received.  From what I can tell this is what the spec says we should
do.

The other bug had to do with improper cursor placement (In DFU and some
other programs).  The cursor would always end up on the first non-bypass
field regardless of where it was really supposed to go.

This was due to improper handling of cursor placement in the
write_to_display command.  Our behavior was correct for a locked display
(move to first non-bypass field).  For an unlocked display, the behavior
is to leave the cursor where it was.  This seemed to be triggered in the
case where we received two write_to_display commands in a row.

I would appreciate it if anyone who is able could check the code out of
CVS and see if this fixes your problems.  Also, if there are any new
problems due to the fixes, I would like to know about them.  I'll be
fixing bugs all week.

Thanks

Mike Madore

+---
| This is the LINUX5250 Mailing List!
| To submit a new message, send your mail to LINUX5250@midrange.com.
| To subscribe to this list send email to LINUX5250-SUB@midrange.com.
| To unsubscribe from this list send email to LINUX5250-UNSUB@midrange.com.
| Questions should be directed to the list owner/operator: david@midrange.com
+---