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.
off-by-one spacing and a missing closing paren bothered me.
I decided to do something about it.
:)
This is what being a good citizen of the internet looks like, right?
set/get_locale are apparently very expensive on Mingw64, and setting
the C locale for extracting a string is unnecessary.
Unfortunately the released version of libdbi still uses strtod so
setting the C locale *is* still necessary for retrieving floats
and doubles and for passing queries.
Thanks to Mkubat for the diagnosis.
The mingw-w64 toolchain bizarrely substitutes scm_to_locale_string()
for scm_to_utf8_string(). This results in latin1 (yeah, "locale" is
a lie) instead of utf8 which causes an assertion in
g_utf8_collate_key().
Perhaps equally bizarre, the compiler doesn't make the substitution
with scm_to_utf8_stringn(), so use that instead.
