[WP34s] serious bug in QtGui version



#12

Hi Pascal,

I've just found a serious problem in your QtGui emulator when using it via the PC keyboard:

I pressed a key a bit longer and expected to see NULL in the display (aborting this operation as in the other emulator), but this didn't work.

Then I made some experiments and found that your emulator doesn't seem to wait for any key-release after a key-press, and so when you press a key a bit longer then the operation is repeated very quickly again and again.

Examples:

1) with 0 in X press [f][B] (i.e. 'sin') and keep pressing [B] for a while. After releasing [B] you get an error message (actually the emulator tries to calculate 1/x for X=0.

2) enter 2 and then keep [D] (i.e. 'sqrt') pressed, and the emulator repeates to calculate the sqrt (very quickly) until you release the key again.

I hope you can fix this bug (maybe by waiting for a key-release before any other function is executed, or even better by implementing this NULL when a key is pressed longer), because this is a serious problem when you're used the other emulators method (NULLing out an operation).

Franz


#13

I may fix it but we do not have the same definition of a "serious" problem.

And I'm not sure that NULLing after a while is the correct behavior for the emulator: the real WP34s reacts to key pressed, not key released and hence does not void the operation after a while.


#14

Quote:
I may fix it but we do not have the same definition of a "serious" problem.

Well, for me it's indeed 'serious' if any function is repeated continuously just because I press the key a bit too long.
Quote:
And I'm not sure that NULLing after a while is the correct behavior for the emulator: the real WP34s reacts to key pressed, not key released and hence does not void the operation after a while.

Hmmm? Have you ever tried Marcus' emulator? Or a real HP-41? They work exactly this way (i.e. canceling the keypress after a while), and this was the reason why Marcus also implemented this (very good!) feature.

Franz


#15

You know for sure how to convince people to help you.

And no, I've never tried Marcus' emulator nor a real HP-41c of course.


#16

Quote:
You know for sure how to convince people to help you.

I don't see why you would/should help me? I'd rather say that I tried to help you in making your emulator better or bugfree.
Quote:
And no, I've never tried Marcus' emulator nor a real HP-41c of course.

Well, after your sentence above about how the 'real WP34s' (whatever this is) behaves (keypress vs. keyrelease, NULLing), I really might believe this statement. ;-)


Edited: 23 Mar 2012, 11:09 a.m.


#17

I think just adding:

if(aKeyEvent.isAutoRepeat()) return true;

to

QtKeyboard::processKeyPressedEvent() and
QtKeyboard::processKeyReleasedEvent()

will do the trick.

I tried it out on Linux and it seems to do what Franz is asking for and for his testcases does exactly the same thing as the real WP-34s.

I could submit the change if you want, however I can't test on windowz or Mac first.

Edited: 23 Mar 2012, 12:34 p.m.


#18

Do not bother, it's in my list and as I have several keyboard changes to do, I'll check what the best solution is and if there is a need for an option to activate it or not.


#19

Pascal, the WP 34S indeed has a NULL built in. It's not part of the emulator. The trick is that most keys have delayed execution that is only carried out on key release. The keyboard driver produces a Kxy key code on key press and a single K_RELEASE on key release (the same for all keys). The latter is used to trigger command execution while the former just decodes the command and stores it. Exempt from this mechanism are only the number entry keys (and ENTER).

The only repeating keys shall be UP and DOWN and DOWN must not repeat in run mode (as opposed to program entry mode). DOWN doubles as SST and this will NULL if held down for a second or so.


#20

Quote:
Pascal, the WP 34S indeed has a NULL built in. It's not part of the emulator. The trick is that most keys have delayed execution that is only carried out on key release. The keyboard driver produces a Kxy key code on key press and a single K_RELEASE on key release (the same for all keys). The latter is used to trigger command execution while the former just decodes the command and stores it. Exempt from this mechanism are only the number entry keys (and ENTER).

Yes, I'm aware of this and was just joking before (shouldn't have). However, it does not apply to 0-9, +/-, CPX, XEQ, ENTER, <-, ->, EEX, ., EXIT...

Quote:
The only repeating keys shall be UP and DOWN and DOWN must not repeat in run mode (as opposed to program entry mode). DOWN doubles as SST and this will NULL if held down for a second or so.

Yes and this is not implemented in the wp34sgui.exe emulator. I've implemented it too including correct support for the arrow keys in the WP34sEmulator but it works only with the keyboard so far. Not when keys are pressed by the mouse.

I would like to support it at mouse-level too but this is slightly more complicated than it seems. First, we have to reimplement the mechanism ourselves and it is not obvious to reproduce the same autorepeat delay & speed as the keyboard. This is a minor issue I met already when implementing another emulator (the Fx702p one).

Also, the WP34sEmulator reacts to button-released, not button-pressed events unlike wp3sgui. The reason was to be closer to GUI-system standards which allow you to void a button-pressed by releasing it outside of the component.

Supporting autorepeat at this level would imply to change it and I prefer to take my time and think about it first.


#21

Quote:
Also, the WP34sEmulator reacts to button-released, not button-pressed events unlike wp3sgui. The reason was to be closer to GUI-system standards which allow you to void a button-pressed by releasing it outside of the component.

I vote for changing it to a more calculator like behaviour which would allow for NULL to work when used with the mouse.

#22

Yes, this is what I think too.


Possibly Related Threads...
Thread Author Replies Views Last Post
  wp34s binomial bug Andrew Nikitin 4 406 09-22-2013, 05:20 PM
Last Post: Paul Dale
  New version of WP34s iOS emulator pascal_meheut 4 513 07-22-2013, 03:55 PM
Last Post: Matt Agajanian
  Expon bug in wp34s Andrew Nikitin 7 611 07-14-2013, 03:23 AM
Last Post: Marcus von Cube, Germany
  another wp34s bug Andrew Nikitin 8 657 06-26-2013, 01:01 AM
Last Post: Paul Dale
  weird statistics bug in wp34s Andrew Nikitin 5 578 06-20-2013, 01:54 PM
Last Post: Namir
  New version of the WP34s iOS emulator pascal_meheut 15 1,091 04-23-2013, 01:58 AM
Last Post: Walter B
  [WP34S] A funny bug in Pi (prod) Eduardo Duenez 3 446 01-28-2013, 03:41 AM
Last Post: Walter B
  [WP34s] Bug or feature? Dieter 25 1,429 01-03-2013, 06:20 PM
Last Post: Paul Dale
  [WP34s] New TVM-solver version fhub 43 2,858 12-26-2012, 06:12 AM
Last Post: fhub
  [WP34S] WP34S firmware on the AT91SAM7L-STK dev kit? jerome ibanes 1 322 10-04-2012, 04:59 PM
Last Post: Paul Dale

Forum Jump: