(get-commoditylist-totalavg-prices) will generate a whole-book
splitlist. This is then filtered to 'interesting' splits only, and
sorted by posted date.
This sorted, filtered list is then filtered to each commodity, and
passed down as argument to (gnc:get-commodity-totalavg-prices) to be
used immediately, rather than calling the expensive function
(gnc:get-match-commodity-splits-sorted) which eventually creates a
query for each commodity.
This report seems to have evolved from a pure asset-liability
chart. It handles income-expense too, so rename to minuend-subtrahend
to be generic.
Also report percentages done.
This will deconstruct process-datelist to not call the utility
(gnc:accounts-get-comm-total-*) functions which are still slow,
because they will cycle through the balancelist for each account. In a
large enough report, the balance list may be thousands of entries
long, and we don't want to cycle through them every time.
This commit will loop all so that the balances are cycled once only.
This will retrieve the cached balances in account-balances, rather
than calling (gnc:account-get-comm-balance-interval)
or (gnc:account-get-comm-balance-at-date) which are very expensive
because they will call xaccAccountGetBalanceAsOfDate which will scan
the account splitlist every time.
This is similar to test-standard-net-linechart but designed to test
date boundaries. Creates book with following entries in bank accounts,
and calculates amounts at each date boundary.
Bank1 Bank2 Bank3
05/05/69 $25
01/01/1970
05/01/70 $25
12/01/70 $10
18/01/70 $15 $50
01/02/1970
18/02/70 $50
01/03/1970
03/03/70 $200
01/04/1970
15/04/1970
The (gnc:strify) function will take an object, and try various methods
to display a useful output. Instead of a cryptic "#<swig-pointer
Split * 55a7079b2660> () # ?" message it can show
"Split<d:02/05/2018,acc:Bank1,amt:$20,val:$20>"
The (gnc:pk) function is a debugging tool. It will dump all arguments
via gnc:strify to console and return the last argument. In addition,
it will print the time stamp since the procedure was defined, and the
delta time since the last (gnc:pk) call.
(gnc:pk "call weird-fn with " acc " = " (weird-fn acc))
(gnc:pk "call another-fn =" (another-fn))
[d2.3243 t2.3243] call weird-fn with Acc<Bank> = Mon<$25.00>
[d0.1000 t2.4243] call another-fn = #t
This would suggest that (weird-fn acc) ran for 0.1 seconds, and
returned a gnc:gnc-monetary object.
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.
Drop translations of the 'gnucash-icon' string from our po files
and add a note for translators to not translate this string or
use the litteral 'gnucash-icon' as translation
Disconnect date edit's focus-out callback before destroying the transfer dialog widget.
This should prevent the callback being triggered while the widget's internal state
is being destroyed.
The issue I found was with File->Print and its variants for various page types.
They all use the same '<primary>p' as global accelerator. It was possible to
have gnucash invoke the 'Print Report...' action instead of the 'Print Invoice...'
action when hitting <primary>p on an invoice page. If no report page was
open at this point, gnucash would crash. If a report was open, gnucash
would invoke the print action on that report instead of opening an
invoice report for the invoice. This looks like a bug internally in
the gtkaction handling or our improper use of it. However I could
work around it by disabling action groups before unmerging them.
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
It was managing a number of redudant parameters which were leaking
memory all over the place. The information that was tracked could
easily be extracted from the underlying GtkTreeView, GtkTreeModel
or GtkTreeSelection when needed.
This reverts commit 5609b704c5.
While it fixed the memory leaks it also caused gnucash to crash
when trying to search for invoices. Will be redone differently
in a follow-up commit.
Before this action would open the cust/vend/empl edit window. However opening the report is a much
more common use case so it makes sense to make that one default.
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,
