Created attachment 373876 [details] Screenshot of the flow. This may be a re-occurrence of an old bug. When I attempt to paste a long value into a register in GnuCash the application disappears. For example create a new GnuCash file and attempt to paste 1,071,353.10 from the clipboard to the "Deposit" column. (This also occurs with Ctrl-V paste attempts). GnuCash disappears and leave the file in an open state; so I assume some sort of exception occurred. This is new with version 4.2. My normal work flow is to copy a value from the web page for my account into the GnuCash register. This value will be in the range above.
Created attachment 373877 [details] Error on re-opening.
Well, that's annoying. I can reproduce it, but not if I've started from the command line and not if I attach the debugger.
Just reproduced it with a second machine. Then did an uninstall and attempted to clean out ALL gnucash directories (.gnucash, aqbanking, C:\Program Files (x86)\gnucash, etc) Same results. But once the value showed up with a missing comma (1071,353.10) and worked. But only once.
I noticed that too, that when it doesn't crash it eats one of the commas. Try starting a command or powershell window and running gnucash from it. Does that crash? 'C:\Program Files (x86)\gnucash\bin\gnucash.exe'
Yes. Command Prompt (normal and as Admin) still fails. I also notice that if I simply try to type in the number the "1," crashes it.
Perhaps title should be: "Exception occurs when number with a comma is entered to the register"
Repro'd on a third machine. This is on wife's fast and new HP laptop. Again type in any number and comma and gnucash disappears. I've gone back to version 4.1 for now. So feel free to set priority here as you deem appropriate. Thanks again.
It's useful to know that it's a regression from 4.1. Also interesting that it crashes when you type a comma: When I do that it just ignores the keystroke.
I have something that may be related in 4.2 that makes me wonder if this isn't connected to https://bugs.gnucash.org/show_bug.cgi?id=797889 which seemed to have been fixed. i am getting === an unhandled win32 exception occurred in gnucash.exe [nnnn] === the nnnn that I have noted so far are 3280, 7128, 5928 so probably not useful. I can make this happen by trying to edit a money market fund value that has 4 decimals. I may just be a president without tax returns pretending to be well but I'm guessing the parsing of numbers other than 999.99 may be involved
OP (John-without-an-R) try the number without thousand seps and only 2 decimals, does that work consistently or fail consistently ?
I can also force an error by pressing DEL with the cursor at the beginning of a "shares" value like x1,081.8 where x is the cursor position and I am pressing DEL in order to change it to 999.99 checked again, repeatable. I think in my example when I press DEL the number goes from 1,081.8 <-- happy with that to ,081.8 <-- wtf ? Trump has been re-elected! and b0rks so thousand seps and decimals seems to match, can't see why it would only be win32 unless linux users never get to use millions or 4 decimals <-- joke :)
mid air collision I was suggesting the importance should be raised as people with non 999.99 currencies might find this very confusing
(In reply to Wm from comment #10) > OP (John-without-an-R) try the number without thousand seps and only 2 > decimals, does that work consistently or fail consistently ? Wm, Entering "number without thousand seps and only 2 decimals" works consistently. For example: 1546999.33 is converted to 1,546,999.33 and works without issue. [Enjoyed the humor]; "John-without-an-R" who is technically John Robert Vermeer (with an R), US birth certificate available on request. ;)
I can reproduce a crash without cut&paste: 1. TAB/CLICK to Debit/Credit column 2. Use keyboard entry to enter "12345678", don't press enter 3. Use keyboard HOME RIGHT "," RIGHT "," RIGHT "," etc I half expected the cell to become "1,2,3,4" but it didn't. This is fine. Cell remains "12345678" 4. At some point (cursor is after 3 for me) "123|45678" pressing , causes a crash.
Minimal keyboard-driven crash using v4.2 Input 12345678 Press Home then Right x3 to place cursor after 3 Press , Crash
ff on from Christopher's test: I tried changing 123.4567 (which is valid for my MMF but doesn't involve thousands) to 123.45,67 <-- I wasn't expecting that to be valid in 1,999.99 number systems recipe 123.45x67 where cursor is x type , collapse. So it seems the comma is the beastie. Other chars tested another period "." 123.45.67 produces a dialog semicolon 123.45;67 just ignored as input space 123.45 67 same as "." produces dialog apostrophe 123.45'67 just ignored as input backtick 123.45`67 just ignored as input underscore 123.45_67 same as "." produces dialog also 123.45*67 also 123.45/67 also 123.45+67 also 123.45-67 seem to be ok but I haven't pushed them (e.g. 123.45 / 1,23.45) because I wouldn't normally do that (i tend to leave out thousand seps, they are, after all, just for display). What I can't easily test is whether this about parsing a comma in a number as a char OR parsing a number sep (i.e. a comma or something else with meaning) which could be spc, apostrophe, point (full stop) or something else in a currency I am unfamiliar with. Bit puzzled as to why (or if) this is Win only. As above, if this is a separator issue AND / OR a comma-in-numbers issue then people with 1.000,00 etc number formats aren't going to find this bug. - 123.45-67 produces the dialog
OP (now known as JohnRV (not John Recreational Vehicle) as distinct from the other JohnR who is (genuinely) a very important person) if you get rid of the thousand seps in your cut and paste you should probably be OK to go back to 4.2 which is, I think, a good step forward. I think ChristopherL and I have given you enough clues on getting numbers from some place to gnc.
Thanks for all the work on this! I will stay on 4.1 for now as it works fine for me. I cannot prove it, but I still recall having seen this in an older version. I must have reported it directly or in the old bug system.
it is a community problem now
Version: 4.1 Build ID: git 4.1-99-gc210ceb3c+(2020-08-22) Finance::Quote: 1.47 [2020.10.12 18:04:36] <CDB-Man_> jralls: one of these days, i need to walk you through several force closes that happen on windows when messing with 3 currency transactions... umless you are already aware of this [2020.10.12 18:15:51] <CDB-Man_> ie when a USD stock account has a CAD parent and I'm inwolving a USD dividend income account [2020.10.12 18:16:13] <CDB-Man_> sometimes when you try to modify one of the 3rd currency splits (e.g. delete the unit price) the app force closes [2020.10.12 18:17:58] <CDB-Man_> https://i.imgur.com/3ZcCwAX.png for example this is the SPY stock account, with a CAD parent. I am editing the split to the USD cash account which is coded in USD, if I try to put a negative sign in the other currency amount to make it -2,500, the app crashes [2020.10.12 18:18:38] <CDB-Man_> i have to clear the entire contents before i can type "-2500" [2020.10.12 18:18:48] <CDB-Man_> just pre-pending the negative sign causes app crash [2020.10.12 18:19:36] <CDB-Man_> also using cut-paste to move numbers between DR and CR causes crash, i have to manually retype the nubmer [2020.10.12 18:20:05] <CDB-Man_> are these known issues,? [2020.10.12 18:20:22] <CDB-Man_> shall i file a bug? [2020.10.12 19:34:36] <jralls> CDB-Man_ might be related to https://bugs.gnucash.org/show_bug.cgi?id=797959. What if there aren't any commas, i.e. if the amount is 500 and you tack on the -? [...] [2020.10.12 21:23:58] <CDB-Man_> jralls: okay, so using the DEL key to clear the contents of the cell also crashes. I guess i have to select all the text to remove the contents. about to try making the number 500 (so no comma) and repeating [2020.10.12 21:25:14] <CDB-Man_> to be more specific: if I place the cursor at the front of the "2,500" in the Other Currency column and use DEL to try to delete the 2, it crashes. if i first select all text before pressing DEL or backspace, that's fine [2020.10.12 21:26:48] <CDB-Man_> jralls: and it looks like your suspecion is directionally correct. 500 is fine, as it lacks a comma
do we know if it is comma as a char or comma as a thousand separator yet? I can't think of an easy way of testing this would someone with a numbering system that uses comma as a decimal rather than a thousands separator or as anythung else let us know what their experience is, please? https://en.wikipedia.org/wiki/Decimal_separator has some interesting discussion on this if anyone else has an idle covid-19 moment and enjoys reading and learning :) I thought gnc was fairly open minded and generous about what it allowed, and then I ... [shaved|consumed alcohol|reused an advert|something else] <-- old advert ref
JohnRV: CDB-Man_'s contribution suggests 4.1 displays the bug too. Which agrees with my experience. Obviously which version you use is your choice but you shouldn't be thunking 4.1 doesn't have this problem.
Wm, I am using Version 4.1+(2020-07-25). I keep an IRA balance up to date on an almost daily basis and exercise the workflow below regularly. In the day's transaction I type in the prior Balance as a Decrease and paste in the current balance as an Increase. The current balance is copied from a web page and includes comma separation (and decimal point). This did not fail until I upgraded to 4.2 and since reverting to 4.1 it does not fail. So, based on my experience I am thinking that 4.1 does not have this problem (for me). Thanks again for a great product and the attention to my issue! [I will see if I can find and test Build ID: git 4.1-99-gc210ceb3c+(2020-08-22)]
4.1-99-gc210ceb3c+(2020-08-22) does not seem to be available to mere 16-bit mortals like me. ;)
(In reply to John from comment #24) > 4.1-99-gc210ceb3c+(2020-08-22) does not seem to be available to mere 16-bit > mortals like me. ;) It is. Apparently you don't know about the nightly builds at https://code.gnucash.org/builds/win32/maint/. (In reply to Wm from comment #21) > do we know if it is comma as a char or comma as a thousand separator yet? I > can't think of an easy way of testing this. It's the thousands separator. You can test by changing your locale (see https://wiki.gnucash.org/wiki/Locale_Settings) to one that uses a different separator. I'd added a little routine to strip thousands separators in an effort to avoid parser errors from misplaced separators, but I had a use-after-free in the loop variable. Easy to fix once I recognized it. But I don't really like the resulting UX because it removes all of the thousands separators when you start an edit. Suppose you have 1,234,567.89 in a number cell. You set the cursor after the 4 and press delete: Now the string is 123467.89. It deleted all the commas and the 5, probably not what you were expecting. Without the comma removal it would leave you with 1,234567.89 and if you tab out it puts up a message box saying that something's wrong with the entry. That's maybe a bit annoying but less so than surprising you with edits you didn't ask for. The rationale for the counting is that apparently some locale uses space as both thousands separator and decimal separator. Of course it's also a value separator and in that case counting digits is the only way for the parser to figure out which one a particular space represents. Reworking that is not something I want to make time for right now so I've simply undone the separator removal. That will be in tomorrow's nightly (and in 4.3.
THANKS! My testing this morning shows "4.2-51-g792d52b48+(2020-10-14)" working as expected. johnRV
@JohnRV yay @JohnR thank you for the commentary, it helps people like me. I would expect 1,234^,567.89 (^ as cursor) DEL to still be 1,234,567.89 so I see why the UX may not be ideal if it DELs the 5. quote === and if you tab out it puts up a message box saying that something's wrong with the entry === that's the dialog I was referring to in #16 JohnR, I think this is a fair fix. IIRC when I last had to deal with this you had to count away from the known decimal in each direction, i.e. however much each nation loved their format, it was the decimal that counted. Aside: quote === apparently some locale uses space as both thousands separator and decimal separator === which (or who) has the space (or any other char) duplicated as decimal and sep ? Were you trying to make Indian subcontinent (or similar) lakh and crore work? If so don't bother, you'd be just as lucky getting "buck", "pony", "monkey", "dollar", etc. working. My advice? Don't try to encode slang in a finance program, if you were trying to do something else, apols.
(In reply to John from comment #23) > In the day's transaction I type in the prior Balance as a Decrease and paste > in the current balance as an Increase. The current balance is copied from a > web page and includes comma separation (and decimal point). None of my business really, just saving you work, but have you considered posting the difference (+/-) to the account rather than the number before and number after? I don't know your circs, but is your workflow efficient? Differences are noticeable, big chunks daily either side of the DR / CR obfuscate the eye.
(In reply to Wm from comment #28) > (In reply to John from comment #23) > > In the day's transaction I type in the prior Balance as a Decrease and paste > > in the current balance as an Increase. The current balance is copied from a > > web page and includes comma separation (and decimal point). > > None of my business really, just saving you work, but have you considered > posting the difference (+/-) to the account rather than the number before > and number after? > > I don't know your circs, but is your workflow efficient? > > Differences are noticeable, big chunks daily either side of the DR / CR > obfuscate the eye. Wm, The web site is providing me the current balance. But it cannot provide the delta since it does not know when I updated Gnucash last. So I am using Gnucash as a simple calculator [lastBalance - currentBalance]. I've tried to automate with aqbanking and with downloaded export files from the web site. But no luck. Thanks for the input.
*** Bug 797991 has been marked as a duplicate of this bug. ***
*** Bug 797999 has been marked as a duplicate of this bug. ***
*** Bug 798003 has been marked as a duplicate of this bug. ***
*** Bug 798032 has been marked as a duplicate of this bug. ***
*** Bug 798037 has been marked as a duplicate of this bug. ***
*** Bug 798051 has been marked as a duplicate of this bug. ***
*** Bug 798056 has been marked as a duplicate of this bug. ***
*** Bug 798134 has been marked as a duplicate of this bug. ***
