While duplicating a payment into next month, I entered the date 12/21 abd 12/21/2019. This messes up my data entry, hiding not reconciled transactions in the distant past.
Have a look at 'Edit->Preferences' and 'Date Completion' mine was set to 11 and did the same but setting it to 10 works. I am not sure if this is a bug or not, still trying to do the math based on tool tip.
See also https://code.gnucash.org/docs/C/gnucash-help/set-prefs.html#prefs-date-time, which needs some update, too. I assume at some point the default changed to 11 because "most users" rarely enter dates more than a month ahead.
A new feature with a bad default is a bug. 11 does not allow dates in the next month but within a month, like my usual credit card payment date after I get the statement online. I am going with 5, like a bill 6 months out. Maybe the developers don't qualify for CC yet? Thanks!
AFAICT the default value is 6 months. @BobIT where did you find it set to 11?
https://github.com/Gnucash/gnucash/blob/979f6acf91555300cb57efa3f412ac0268ae4e81/gnucash/gtkbuilder/dialog-preferences.glade#L35
So it is 6. I was wrong, sorry for the noise.
(In reply to John Ralls from comment #4) > AFAICT the default value is 6 months. @BobIT where did you find it set to 11? I was not sure that I had not changed this but as pointed out by Frank the glade file says 6 but I found the cause, the gschema file org.gnucash.gschema.xml.in entry is 11. I will push a change to make it 6 like the glade file.
Is it possible to have only one default?
(In reply to Frank H. Ellenberger from comment #8) > Is it possible to have only one default? In this situation the glade default is not involved, it is the gschema default value that is used to populate the widget. Unfortunately the glade file needs some value for default, if left blank it would be 0.0
That doesn't make sense. Either the GSettings default populates the widget and the default in the GtkBuilder file is irrelevant or GtkBuilder populates the widget and it's the GSettings default that's irrelevant.
I am not sure what does not make sense. When you edit the glade file, if you leave the value field blank it fills it with 0.0. When the glade file is loaded with GtkBuilder, the value is populated from the GSettings and if not changed will be the default value now 6.0
OK, the statement makes sense now. I guess it would be better if Glade displayed something like <not set> or <no default> instead of inventing a value, but that's a Glade problem completely irrelevant to GnuCash.
Commit 0484607 updates the default in help.
Bob, I assume, we can remove the translatable flag from at least numerical defaults in glade files, if gsettings will win?
Frank, If I understand you are talking about things like 'auto-decimal-places' in dialog-preference.glade. I think that is correct, if it just a number, why does it need translating. I had to confirm this by looking at a po file, I had not noticed it before.
From Comment 15: > Frank, If I understand you are talking about things like > 'auto-decimal-places' in dialog-preference.glade. > > I think that is correct, if it just a number, why does it need translating. Just for comleteness: applied in commit 1a32fe1 and 861fc21. From Comment 7: > I will push a change to make it 6 like the glade file. David, can you test the fix in a nightly?