I think the lnReqAmount should be formatted as the the other fields that accept bitcoin amounts, so with an up-and-down field that autocorrects "." and "," (or even better with a BitcoinAmountField so that you can choose the unit). As is you can insert spaces in the lnReqAmount and the spaces will be used to calc the QR Code (because the lnReqAmount.text() is used directly)
-
xanatos commented at 6:12 AM on June 23, 2012: none
-
Diapolo commented at 10:11 AM on June 23, 2012: none
Seems like a pretty good idea, will look into this :).
-
Diapolo commented at 4:29 PM on June 23, 2012: none
Working on this, I currently only have a small problem with updating the unit, as we don't have WalletModell or OptionsModell available in the qrcodedialog code.
-
xanatos commented at 5:12 PM on June 24, 2012: none
@Diapolo My only problem is with the BitcoinAmount::validate()... It does two different things... It checks for non-zero value and checks for "textual" correctness and number-of-digits validation (the last two checks in the parse() call). I do think the non-zero value test isn't correct to be put there (and, for example, the MainOptionsPage doesn't use the validate() method probably for this reason, because 0.00 commissions are ok). Considering the BitcoinAmount::validate() does a "textual" validation and a number-of-digits validation, I would stop the QR code from being generated if it isn't valid.
I'll note that there is even a minor bug in the save-as button. If you put too many letters in a field the QR code on the screen will disappear, but the save button will save the last correctly generated QR code.
- xanatos closed this on Jul 13, 2012
- suprnurd referenced this in commit d787fe4ab6 on Dec 5, 2017
- lateminer referenced this in commit 8dd66ed4d8 on Jan 22, 2019
- MarcoFalke locked this on Sep 8, 2021
