Comment #3 from Charles Day    (GnuCash developer, points: 13)
2009-04-30 22:34 UTC [reply]

Can the first bug be worked around (for now) by left clicking on the split
before right clicking on it?

Comment #4 from Charles Day    (GnuCash developer, points: 13)
2009-04-30 22:37 UTC [reply]

Can the second problem still be reproduced with the trunk SVN code? There have
been quite a few register fixes lately in trunk.

Comment #5 from David Ward    (reporter, points: 2)
2009-04-30 23:04 UTC [reply] 

Phil, you're right, I would consider them as separate bugs.  It's more
difficult to reproduce the behavior in the second bug at will, so I was kind of
hoping that it was all related to whatever was causing the first one, so that
it would be easier to see if a fix really happened...but I certainly realize
that may not be the case.  If you think a fix may already be in place, I'll
update to the latest SVN and give it a try as early as this weekend and let you
know (I'm sure I would catch it because I have a lot to enter).

Comment #6 from David Ward    (reporter, points: 2)
2009-04-30 23:08 UTC [reply]

To clarify, yes the second part is the real problem for me.  And that is what I
was assuming there might already be a fix for that I would try out, from
Charles's comments.

 Comment #7 from Charles Day    (GnuCash developer, points: 13)
2009-04-30 23:11 UTC [reply]

I doubt the first problem would be fixed. I'll have to look at that. Does the
workaround described in comment 3 work?

For the second bug, it might be fixed. But it still happens, does using the
comment 3 workaround make any difference?

Comment #9 from David Ward    (reporter, points: 2)
2009-04-30 23:41 UTC [reply]

If I remember correctly that was the workaround that I used too (although I'd
inadvertently click elsewhere anyway out of habit).  I don't know of any second
workaround for the second bug though.  I can try that workaround again this
weekend to verify.

Sorry for the delay.  I had final exams last week, and I now have only intermittent Internet access until early next week.

I tried to test the behavior in my original bug report, but now I can't even get that far because the application seems to have regressed further, to the point that the exchange rate functionality is completely broken.

Please try the following steps:


1. Create a new file with USD as the default currency and "A Simple Checkbook" as the template.

2. Create an additional checking account in this file with EUR as the currency.

3. Open one of the checking accounts and select the "Transaction Journal" view.

4. Start a new transaction to transfer money between the two checking accounts.  Choose the two amounts so that the exchange rate is not 1:1.  For example,  credit 125.00 EUR and debit 100.00 USD from the respective accounts.

5. When you create the entry that uses the other account's currency, the exchange rate dialog will appear.  Enter an exchange rate that should balance the transaction.  For the above example, 1.25 EUR = 1 USD or 1 USD = 0.8 EUR.  Click OK.

6. Attempt to complete the transaction.

At this point, you should notice a bug.  Although the transaction should be balanced, another entry will appear showing an imbalance.  The amount of the imbalance will assume that the exchange rate between the two currencies is 1:1, despite the fact that you entered an exchange rate.


My original problem may have been fixed but I don't know.  Please clone the above into a separate bug if necessary.

Again I will have limited Internet access until early next week, but otherwise I will be happy to do whatever I can on my side (such as testing), to bring a full resolution to all of these bugs affecting exchange rates in Gnucash.

Just for clarification, I am using latest SVN (rev 18067), which is exhibiting the bug in my previous comment.  My current environment is Ubuntu 9.04.

I'm not sure this is actually a bug.  Assume in your example you have the USD checking account open.  When you enter the transaction in that account, it must balance in USD, so you need 100.00 as both credit and debit.  However, when you enter the 100.00 USD on the line corresponding to the EUR checking account, the dialog should pop up and allow you to enter the exchange rate or final value.  For me, this happens when I get a known amount of US$ using a Canadian$ checking account or credit card.  If I get 100.00 US$ for 125.00 C$, I enter a credit of $125.00 C$ in my credit card account and 125.00 debit in my US$Cash account.  The dialog pops up and I set 100.00 as the value (I let it calculate the exchange rate).  I think the imbalance is there because you have entered it as an imbalance (when you enter 125.00 EUR in a US$ account, gnucash is treating it as 125.00 US$, so there's a 25.00US$ imbalance).

I don't know what the documentation says about entering multi-currency transactions, but it is easily possible it could be improved.

Oh I see, that makes sense.  Either GnuCash works differently than it did a few months ago, or (more likely) I just forgot :)  That part is indeed working as you said...you can just ignore my previous comment.  

I'll now try to test my original bug.

Yep, this is not a bug. It's just working different than you expected. The numbers displayed within a particular register are all in the same currency. So in a USD account register you would enter the USD amounts, then enter the amount in the other currency when the exchange rate dialog pops up.

At some point it would be really nice to show the currency in the register in a more obvious way, or let the user type in "100 EUR" or "100 USD", etc.

After messing with this a lot more, I can still reproduce this bug quite often, but I can't find any way to reproduce it consistently.  I am seeing the bug occur even when I create a completely blank file using the "A Simple Checkbook" template, and then I add a foreign currency checking account and just one multi-currency transaction.  I can't find any pattern at all to when it seems to accept my exchange rate changes and when it seems to ignore them.

I thought twice that I had finally gotten a demo accounts file that I created into a "broken" state, where the exchange rate couldn't be edited for a certain transaction.  But just before I was going to attach the demo file to this bug, it suddenly started working again.

I tried examining the contents of the XML transactions between files and I couldn't see any significant differences.

The only logical thing that I could suggest (without knowing the code) is that some form of memory corruption is occurring, such as not initializing variables before they are used?

Would it make sense to mark this bug as depending on 567709, wait until that one gets ironed out, and then go from there?  My opinion is that if the observed behavior is in any way a result of compound bugs, it may be easier to narrow this down if we can isolate the behavior for this specific bug, which we can't do while the other bug is still unfixed.

I really appreciate everyone's attention to this, and apologize for my memory lapse earlier today on the correct way to enter a multi-currency transaction (I hadn't tried this since first reporting the original bug).  Something is definitely up, and I'd like to work with you to straighten this out.

OK, I'll try to fix bug 567709 first. Then we can revisit this and see what we find.

Findings with gdb:

Each time that the "Edit Exchange Rate" command is issued on an existing transaction, 'gnc_split_register_handle_exchange' is called by 'gnc_plugin_page_register_cmd_exchange_rate'.

'rate_cell->cell->value' holds the exchange rate value, and it is properly read and updated during this function call.  If you change the exchange rate in the dialog, click 'OK' in the dialog, and then immediately issue the "Edit Exchange Rate" command again on the same split (without clicking on another split first), then the value of 'rate_cell->cell->value' is initialized to the value that was entered when the dialog was last closed -- as expected.

However, the problem is seen when clicking on another split after modifying the exchange rate.  'gnc_split_register_handle_exchange' is now called again, but this time from 'gnc_split_register_traverse'.  'rate_cell->cell->value' is being read as the original value of the exchange rate, ignoring any changes made by the user through the exchange rate dialogs.

The problem seems to be how the exchange rate cell is not being committed somewhere in a higher-level function.

Created attachment 136700 [details] [review]
Contributed fix

Found and fixed the problem!!!

First, this bug ONLY happens if the 'account' cell in the current split is active anytime between when the exchange rate is changed, and when clicking on a different split or transaction.  (The account cell happens to be what I always right-click on to select "Edit Exchange Rate".)

'gnc_split_register_handle_exchange' calls 'gnc_split_register_get_account_always', which then calls 'gnc_split_register_get_account_by_name'.  This last function causes the account cell in the current split to be marked as changed (even though through this code path, it is not).  Then after setting the exchange rate, if the account cell in this split ever has or gets the focus, 'gnc_split_register_check_account' will be called once it loses the focus.  This function resets the exchange rate to its original value when it detects that the account cell has been changed.

The patch modifies 'gnc_split_register_get_account_always'.  It replaces its call to 'gnc_split_register_get_account_by_name' with the few relevant lines that I believe are needed from that function.  Consequently it avoids marking the account cell as changed.

There may be a more preferred way to do this (such as adding a parameter to 'gnc_split_register_get_account_by_name' that determines whether or not to change the account cell), but this should give you the idea.

FYI, this bug turns out to be completely independent of 567709 (from which this was cloned).  You can remove the 'depends on' setting if you'd like.

It looks like there is a second bug as well. The first, which you have described, marks the account cell as changed when in fact it has not been. The second bug is that even if the account cell is genuinely changed, the exchange rate gets reset every time that focus passes through the cell (rather than only when the account cell is changed again.)

One disadvantage with your patch is that it removes one opportunity to automatically create a new account. For example, in the unpatched code you could enter a figure in the amount cell, then enter the account cell and type a new account name then, without leaving the cell, right-click to edit the exchange rate, and it would ask if you want to create the account.

I've committed a fix in r18166. It seem to fix this problem for me. Does it look like it works for you?

I've opened bug 587913 for the behavior of marking the account cell as changed even when it hasn't been (see comment 10).

GnuCash bug tracking has moved to a new Bugzilla host. This bug has been copied to https://bugs.gnucash.org/show_bug.cgi?id=580968. Please update any external references or bookmarks.