[WP34s] serious bug in QtGui version

[fhub]

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

[pascal_meheut]

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.

[fhub]

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

[pascal_meheut]

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.

[fhub]

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.

[Dominic Richens]

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.

[pascal_meheut]

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.

[Marcus von Cube, Germany]

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.

[pascal_meheut]

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.

[Marcus von Cube, Germany]

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.

[pascal_meheut]

Yes, this is what I think too.