https://bugs.kde.org/show_bug.cgi?id=522826
Bug ID: 522826
Summary: Amount field sometimes changes the entered value when
focus is lost or the dialog is accepted
Classification: Applications
Product: kmymoney
Version First 5.2.2
Reported In:
Platform: Other
OS: Linux
Status: REPORTED
Severity: normal
Priority: NOR
Component: ux-ui
Assignee: [email protected]
Reporter: [email protected]
Target Milestone: ---
DESCRIPTION
In KMyMoney 5.2.2 built against Qt6/KF6, amount fields sometimes change the
entered amount after the field loses focus or after pressing OK/Enter.
For example, I enter 86,00 € in an amount field. When focus changes, or when I
accept the transaction, the value sometimes becomes 8,60 € instead.
This does not happen 100% of the time, but I can reproduce it fairly easily. I
have seen it in different places where KMyMoney uses amount input fields,
including normal transaction entry, scheduled transaction
entry, and split transaction entry.
STEPS TO REPRODUCE
1. Open an existing KMyMoney file using a locale/currency format with comma as
decimal separator.
2. Create or edit a transaction, scheduled transaction, or split transaction.
3. Enter an amount such as 86,00 € in an amount field.
4. Move focus to another field, press OK, or accept the transaction.
OBSERVED RESULT
Sometimes the entered amount is changed from 86,00 € to 8,60 €.
EXPECTED RESULT
The amount field should keep the exact value entered by the user. Entering
86,00 € should remain 86,00 € after focus changes or after accepting the
dialog.
SOFTWARE/OS VERSIONS
Operating System: Mageia 10
KDE Plasma Version: 6.5.5
KDE Frameworks Version: 6.22.0
Qt Version: 6.10.0
KMyMoney Version: 5.2.2
ADDITIONAL INFORMATION
This looks like an issue in the common amount editor widget, because the same
behavior appears in several places that use amount fields.
The issue may be related to AmountEdit reformatting/parsing the value on
focus-out, or to stale value/shares or exchange-rate state being applied when
the amount editor updates. The low-level money parser
itself does not appear to simply convert 86,00 to 8,60, so the problem is
likely in the widget/editor state handling rather than only in decimal
separator parsing.
--
You are receiving this mail because:
You are watching all bug changes.
