This commit contains another round of cleanups in the
timespec to time64 conversion. There were a number of
false assumptions that time64 = 0 would be a bad date
in the xml parser. This commit corrects enough of them to
eliminate the bug. Further cleanup is probably advised but
can be done at a later stage.
Also Bug 791825 - Accounting Period dates off by 1.
The DST start/end dates were reversed *and* the DST offset had the wrong
sign in Windows, resulting in the effective timezone always being one to
the west off (i.e. PDT was -9 and PST was -8).
This affects only Windows and OS X gnucash users. On linux we use
webkit2 for our report handling which has the opposite issue, namely
that both buttons will open the print dialog and it's no longer possible
to effectively export directly to pdf (though one can choose print to file
in the print dialog as a work around). This inverse issue is tracked separately in
https://bugzilla.gnome.org/show_bug.cgi?id=787018
Take 3: Catch encoding exceptions from trying to read a string into
Scheme using scm_from_utf8_string and try again using
scm_from_locale_string. If that throws too, give up and log a
warning.
The budget view had hard coded black for normal values and dark grey for
other values. Changed this so normal values are reset to default color
and adjusted the grey based on default color for theme.
When editing cells that have been revealed on the right by scrolling the
window snaps back to the left hiding the cell being edited. This may be
due to an underlying gtk issue but these changes fix the issue visually.
When the tip_of_the_day.list is created a new line is appended to the
list file and on Windows this causes a blank tip so remove the adding
of the extra line.
When the mouse was placed over a saved report description on Windows an
empty tooltip was displayed. Setup the query tooltip callback so it does
not display a tooltip for description column.
When you double click on the saved report description nothing happens.
This was down to a conflict on a couple of call backs and one of them
was incorrectly setup.
First, remove the unnecessary locale push & pop on <CT_TIME64>load.
Second, the registry accesses were caused by using g_win32_get_locale
to convert the Microsoft locale strings to POSIX ones. We don't care
what kind of string we get as long as we can pass it back to setlocale,
so remove that.
Third, gnc_push/pop_locale were used only in backend/dbi in a
very limited way and did much more than was necessary, so
convert them to C++ inlines in gnc-backend-dbi.hpp that does
only what we need them to.
properly - corrupted business data
Turned out to be a pointer/value mismatch between <CT_NUMERIC>load()
and most of the setter functions, so the address was getting set
as the value.
This crash started to appear as of commit 80dbb9940b because the sequence
of split loading has changed as a result of the query optimizations.
Invoice transactions get loaded before the general transaction loading happens.
However because of this, when an invoice transaction was encountered again
during general transaction loading, it was (correctly) not created again
AND (incorrectly) not opened for subsequent editing. This caused
an assert to fail when the splits for this transaction are loaded
shortly afterwards. The solution is simply to ensure all transactions
are opened for editing during the general transaction loading call.
