This switches swig to use python 3 specific features when generating the
bindings, switches the build over to python 3 and makes the neccesary
python 2 to 3 conversions in the bindings and tests.
The crash was caused by the timezone constructor encountering a
newline on the timezone. Prevent this by removing all whitespace
from the end of the input string.
Four date elements were affected: GncEntry::date, GncEntry::date_entered,
GncInvoice::opened, and GncInvoice::posted. The problem arose during the
cleansing of Timespec from the reports; the setter functions for those
elements were converted to time64 but no provision was made to the SQL
backend to pass them time64 instead of Timespec*.
This commit adds a new column type, CT_TIME64, and changes the column
types for those elements to CT_TIME64.
The import-map-bayes uses a three-part key that uses the same delimiter
as a path and the SQL backend was throwing away everything except the
account guid.
Added more slot types including import-map-bayes ones to the test xml
file to help debug this and to catch it in the future.
Also don't pass std::string.c_str() to a std::vector<std::string>
constructor, just pass the string.
Date field and pressing escape.
gtk_widget_destroy() ran the signals on the dialog controls which
tried to access the XferDialog data, but since gnc_xfer_dialog_close_cb()
had already run that memory had been freed and then used by the std::string
in GncDate::format; later handlers attempting to access the XferData had
garbage pointers to work with, causing a crash.
Running gtk_widget_destroy() first preserves the pointers long enough for
the dialog control callbacks to function without crashing.
unittest_support.py is in ${CMAKE_SOURCE_DIR} for a tarball build
and ${CMAKE_BINARY_DIR} for a vcs build. Look for it rather than
assuming it's in ${CMAKE_BINARY_DIR}.
I ran into this while trying to load a utf-16 encoded file
and loading a saved preset using utf-8. By applying the preset
the columns in the utf-16 file were no longer detected, but
the importer was still trying to read from a preset account column.
This information is not relevant outside of the settings code
The way it's implemented now each settings module defines its
own unique prefix and the generic code can just use it when
needed.
Make it more RAII, in that whatever the class allocates, it should
also deallocate. This simplifies a couple of memory handling cases.
The only exception is the generic import matcher that for some reason
has chosen to deallocate itself. To be fixed when more importers are
converted to c++
As the assistant code combines multiple memory management models care should be taken
not to mix them up. The notes should give some insights in how to do this.
Also fix a few minor issues
- delete default copy and move constructor/assignment for the assistant gui class
- nullify a freed pointer
