On Nov 15, 2014, at 4:44 PM, Christoph Holtermann c.holterm...@gmx.de wrote:
Am 16.11.2014 um 00:13 schrieb John Ralls:
On Nov 15, 2014, at 12:59 PM, Christoph Holtermann c.holterm...@gmx.de
wrote:
Am 15.11.2014 um 18:45 schrieb John Ralls:
On Nov 15, 2014, at 7:32 AM, Christoph Holtermann c.holterm...@gmx.de
wrote:
Hello,
some time ago I found that changes to customer data in the GUI are not
being
saved. When working on a company object i made qof_instance_set_dirty
return a debug message. I found that when changing text in gncAddress
this is not being triggered. When in the GUI I change the state of
activity
the object gets marked dirty (and the text is being saved, too). Same
thing
when using the python bindings.
There I see that SetActive is a method of gncCustomer, while the other
ones
are of gncAddress.
I guess I shouldn't copy this behavior to my company object.
Is this bug known ?
I'll try to find out where it lives.
Customer address or Company address? I know that the Company data is
written directly to KVP in Scheme and that I missed it when I went through
all of the C KVP code last year to make sure that the containing object of
KVP was properly marked and committed. If customer addresses are also
getting missed, that's new.
You're using the SQL backend, right? I ask because saving an XML file
copies everything in memory to a new file; that's why there were so many
instances of writing data without committing it existed. It worked without
committing in XML, so laziness was rewarded.
I'm using SQL. Only Customer address change fails. Company address change
works.
Address goes like
G_INLINE_FUNC void mark_address (GncAddress *address);
void mark_address (GncAddress *address)
{
address-dirty = TRUE;
qof_event_gen (QOF_INSTANCE(address), QOF_EVENT_MODIFY, address-parent);
qof_event_gen (address-parent, QOF_EVENT_MODIFY, NULL);
}
while in my Company object I use (as in gncBillTerm.c or Commodity or
Customer ...)
G_INLINE_FUNC void mark_company (GncCompany *company);
void mark_company (GncCompany *company)
{
qof_instance_set_dirty(QOF_INSTANCE(company));
qof_event_gen (QOF_INSTANCE(company), QOF_EVENT_MODIFY, NULL);
}
in my case it produces the error
CRIT gnc.backend.sql [gnc_sql_commit_edit()] gnc_sql_commit_edit():
Unknown object type 'gncCompany'
when I change mark_address to also call
qof_instance_set_dirty(QOF_INSTANCE(address));
an identical error message is being shown. And the changing of address
doesn't get saved.
So I guess that
1) my company object should rather behave as address in generating an event
to tell it's parent, that
it's dirty. Which would be book. Because book gets saved.
1b) There are object that get saved and then there are others that get
saved by their parents.
2) The communication between parent Customer and child Address about
dirtiness and saving is not
working.
Hello John,
Christoph,
Since you’re using the SQL backend you probably want to study
http://wiki.gnucash.org/wiki/SQL. Once there you’ll notice that there’s no
table at all for Company; as you know already, that’s implemented entirely
in KVP hanging on the Book object. You’ll also notice that there’s no
address table: The schema is denormalized with gncAddress’s fields included
directly in customers (twice, once for billing and once for shipping); also
once each for employees and vendors, so in those cases the commit code will
have to determine which object the address goes to and do the change inside
a an edit-mark-commit block for that object. Please file a bug on that. I
don’t expect you to fix it yourself!
well, fixing the bug may be easier than creating a new class ... anyway I'm
trying to understand how saving object properties works because I need to do
that for the company
object. And it's somewhat the same pathes the bug at address may be at. But
filing a bug report is surely a good idea.
By following what the address class does I realized the difference you
mentioned between address and company. address has SQL rows of it's own, the
company values
are stored in KVPs.
The question is on what level should the company class let the book class do
the work of saving.
Does it need to go the way through
qof_commit_edit_part2 (company-inst, gncCompanyOnError,
gncCompanyOnDone, company_free); ?
It gets rejected when getting to the SQL backend because it's not known as
said above.
Actually just calling for example qof_book_set_string_option(company-book,
options/Business/Company Email, email); works fine where the book class
does all the work.
So there's no need to call qof_commit_edit (part 1 or 2).
But shouldn't all qof-objects behave call these functions ?
For your Company class you can either use gncAddress to handle editing the
address or you can just have a set of
