Store Number Range option values as a pair '(percentage . value) or '(pixels .
value) depending on the size of value as 4.x and earlier expect. When reading a
stored number range option handle the possibility that value is fixed
point (e.g. 50.0) as 4.x and earlier emit, avoiding a crash.
Looks like a SWIG bug, creating an extra variable that it doesn't use
bindings/python/gnucash_core.c: In function ‘_wrap_xaccAccountGetReconcileLastDate’:
bindings/python/gnucash_core.c:10096:10: warning: unused variable ‘secs20’ [-Wunused-variable]
10096 | time64 secs20 ;
| ^~~~~~
bindings/python/gnucash_core.c: In function ‘_wrap_xaccAccountGetReconcilePostponeDate’:
bindings/python/gnucash_core.c:10298:10: warning: unused variable ‘secs20’ [-Wunused-variable]
10298 | time64 secs20 ;
| ^~~~~~
bindings/python/gnucash_core.c: In function ‘_wrap_qof_query_date_predicate_get_date’:
bindings/python/gnucash_core.c:20237:10: warning: unused variable ‘secs20’ [-Wunused-variable]
20237 | time64 secs20 ;
| ^~~~~~
Instead of a gnc:split->owner, use gnc:make-split->owner instead which
generates a split->owner function with its own hashtable. This
function (and its hash table) will be garbage collected in due course,
triggering the gncOwnerFreeing of all owners.
This is a better approach than gnc:split->owner which maintains a
single hash table. It could be buggy: a report calls gnc:split->owner
to query a split, fails to reset its hashtable via #f; the split's
owner is assigned or modified, and the next call to gnc:split->owner
will return the incorrect cached owner.
Compatibility function for passing symbols or numbers as the default
value.
Note that this isn't used by GnuCash code and so isn't exercised or
tested, it's provided only to simplify user-written code migration.
Don't create a new book in the new-user dialog unless the user says to.
Don't automatically create a new book when retrieving default commodities
because the retrieve might be requested in a context like the Preferences
dialog when there is no book.
Some report tests relied on requesting the default commodity creating
the book, so in those tests ensure that the book is created first.
With XCode 14 or newer CMake tries to use the "new build system" which has a
requirement that if two targets depend on the same generated file one of them
must depend on the other. This commit adds reduntant dependencies to satisfy
this requirement.
Enables full functionality for complex-boolean and multichoice-callback
options.
Note that setter-function callback isn't used in any GnuCash code so it
is not implemented and is not present in the register-callback functions.
The root cause of which is that on recent releases of GLib (recent
meaning 2.66 in the current Debian stable!) g_type_instance_get_private
looks in the wrong place for the private data. When running the script
in question it returned NULL and since the code didn't check for a valid
pointer, it crashed.
So this change replaces all calls to g_type_instance_get_private with
the function [type_prefix]_get_instance_private() added in glib-2.36
except for two register2 files that have been removed from master; those
are ignored to avoid unnecessary merge conflicts.
Separate the "All noncurrency" convenience category in the commodity
selector and the default non-commodity namespace proposed by the QIF
importer because they have different functions.
Also remove the namespace guessing code from qif-dialog because with
only one default non-currency namespace there's nothing to guess.
Python bindings already have some wrapping objects for
qof predicates. This adds the one missing for GncNumeric
comparisons.
Additionally fixes a wrong number for QOF_NUMERIC_MATCH_ANY
in example file.
Leave it to users to categorize their non-currency commodities. In the
QIF importer default non-classifiable commodities to
GNC_COMMODITY_NS_NONCURRENCY.
The original merge was of a PR based on master into maint, bringing
along all of the development changes in master along with it. We don't
want that so the merge was reverted and the PR's two changes
cherry-picked in. That fixed maint, but then the next regular merge of
maint into master naturally included that revert commit undoing the
changes in master. Not so good. Reverting the revert, this commit,
restores the changes, albeit with messed up history.
Splits' value and amount should never be of opposite signs. Fix
test book which had created this incorrect value/amount
pair. Strengthen env-create-multisplit-transaction to disallow
test book errors.