date-posted to not be saved.
Check the stored GDate for being in the GncDateTime range as well
as the GDate range before returning it and check trans->date-posted
against INT64_MAX instead of 0 before changing it.
The first fix for this bug handled structs tm with ambiguous times.
This one fixes the GncDate constructor when the time is ambiguous
because it's in the DST-change hour, using the same add 3 hours,
construct the LDT, and subtract the 3 hours from the result.
The string constructor handles only simple-offset HH:MM timezones and so
is immune to the bug.
When the preference dialogue is loaded and options are set, the ones
with registered callbacks fire causing parts of Gnucash to be updated.
This was observed with gnc_split_register_load being executed 5 times
for each open register when the preference dialogue was loaded.
To overcome this, a couple of functions have been created to block and
unblock all registered prefs and used while the preference dialogue is
loaded.
And don't ask to save a not-dirty or empty book, fixing
Bug 794870 - If no book is opened, gnucash still asks if the user wants
to save changes when opening a file
These are queried continuously by the owner tree view (on Customer/Vendor/Employee
Overview pages) and recalculating them is an expensive operation.
The cache will be invalidated each time a lot reated to the owner
changes (modify or delete). The net effect is a huge responsiveness
improvement of said overviews in case of a large book.
Any operation that can overflow will throw an underflow if it's a
negative number. The C interface needs to catch both to prevent
unhandled exception crashes,
That is let the percentage increase gradually. The current granularity is still
very rough, but at least it gives an indication of getting closer to fully
loading the data. The previous configuration on the other hand only suggested
something was happening but with no indication where in the load process
gnucash was.
This prevents calling xaccAccountRecomputeBalanceInCurrency on each split that gets added,
which was exponentially increasing load times. On a huge test book the
load time dropped from 53 minutes to 1m20s.
The core issue was that the delete visitor was never called because its parameter
type (char *) didn't match the boost::variant type (const char *).
Fixing the visitor's parameter type also require a const_cast
back to char * because that's what g_free takes as argument.
The rest of this commit is merely fixing KvpValue instantiations that
tried to create a char* KvpValue from a stack based const string instead
of a heap allocated one. That would bomb out on calling the
delete visitor.
Splits were not marked for deletion if the transaction is read-only
and the account is not marked for deletion yet. The net result is
that split will not be freed later on.
However xaccSplitDestroy is also called from a Transaction's do_destroy.
At that point accounts are not necessarily marked for deletion yet (like
is the case when a datafile is closed). This turned out to be a problem
for invoice post transactions (which are also read only) and hence
would cause memory to leak.
Always use absolute paths for configured directories (BINDIR etc.)
Abstract out the guts of gnc_gbr_find_foo_dir for foo in lib, bin, and data.
etc requires special handling because of the way it's treated if prefix
begins with /opt.
Always fall back on the configured directory if binreloc is disabled and
no default is passed in.
Casting a char* to a struct containing a uint32_t is not universally safe
due to alignment constraints on reads on some platforms. Copy our possibly
unaligned source data into an aligned area of memory to avoid SIGBUS on
armhf.
Reported by vorlonofportland in PR#403. This commit the John's optimized
version of Vorlon's proposed fix.
- add -Wno-deprecated-declarations to CXX_FLAGS as well. This was
reported by vorlonofportland in PR#401 to become necessary for glib 2.58
as that has deprecated g_type_class_add_private which appears in our
c++ code.
- change -Wno-deprecated-register into -Wregister. The former appeared to
be a clang dialect and alias for the latter (see
https://github.com/Barro/compiler-warnings for an overview of clang
and gcc warnings). It was moved to global CXX_FLAGS as it can only be
added for g++.
