This change will fix 'num-of-weeks-since-1/jan/1970' which formerly used quotient to remove
the fractional part of the division. For negative values of num-of-weeks, the number is truncated
in the wrong direction (i.e. towards 0). This change uses floor instead to ensure the num-of-weeks
found is the nearest integer LESS than the fractional number.
Commit 88b8477 on libdbi calls the error handler if one attempts to run
off the end of a result set. Since we often loop on
dbi_result_next_row() returning 0 this breaks our logic in several
places. This change simply returns from the error handler on a
DB_ERROR_BADIDX allowing the logic to work as before.
intltool-update should be run from the build directory, not the source directory.
If run from the source directory it will omit glade messages that have a context attribute
so all msgids with a msgctxt comment would be missing.
On the C side an SCM guile_options object is wrapped in a GNCOptionDB. This is
however a multi-to-one relationship. That is there can be several GNCOptionDBs
wrapping the same SCM guile_options object. This happens for example when
a report is open together with its Options dialog. Both manager their own
GNCOptionDB object while both wrap the same SCM guile_options.
The problem in this bug was caused by a callback function picking the wrong
GNCOptionDB based on the given SCM guile_options object. Which GNCOptionDB
got picked was completely dependent on how g_hash_table_foreach would cycle
through the stored dbs. It appears this is dependent on the in-memory order
of the hash table's values.
By being more selective of which GNCOptionDB we're looking for, this
could be circumvented. The GNCOptionDB we want is the one related to the open
report options dialog. This GNCOptionDB is different from the one managed by
the report tab in that it has callbacks set. So from now on we search for
a GNCOptionDB that wraps the give SCM guile_options and has one particular
callback set.
