GNOME Bugzilla – Bug 647805
Interdependent report options fail to change state after using apply for a limited number of times
Last modified: 2018-06-29 22:56:53 UTC
Overview: It's possible to select Notes without selecting Memo in the Display Options Dialog for the Transaction Report. Applying changes with Notes selected and Memo de-selected causes Totals columns to align off to the right of other values. Other options do the same, though. See: bug 405750 Steps to Reproduce: This is the only way I've been able to get this to happen so far, but I know it happens at other time when I'm doing some heavy and fast clicking of options and applying them without closing the options dialog. 1) Open Transaction Report with all options at default. Choose an account. Apply changes. Cancel out of dialog. 2) Reopen options and go to display tab. 3) De-select and Re-select Memo - Notes option should be be un-grayed/grayed out accordingly. 4) Hit Reset Defaults and Apply. 5) Go to step 3. Actual Results: On every third round of doing steps 3 and 4, the Notes option is un-grayed/grayed correctly, but on the other two rounds the selection of Menu has no effect on Notes. Expected Results: Notes should always be grayed out when Menu is not selected. Build Date & Platform: svn r44b6981+ on 2011-04-08 with Ubuntu 10.10. Additional thoughts: There may be two bugs here. One with the options dialog and some of the functions in the code at line 859 in transaction.scm: ;; Add an option to display the memo, and disable the notes option ;; when memos are not included. (gnc:register-trep-option (gnc:make-complex-boolean-option gnc:pagename-display (N_ "Memo") "d" (N_ "Display the memo?") #t #f (lambda (x) (gnc-option-db-set-option-selectable-by-name gnc:*transaction-report-options* gnc:pagename-display (N_ "Notes") x)))) And another in how the rest of the report process the Memo and Notes options which causes the totals to be misaligned depending on which options are selected (again, see bug 405750).
I tried to reproduce this bug with GnuCash 2.5.0 on Ubuntu 12.04, but it did not manage. The notes checkbox is always grayed correctly. @Joshua: Can you confirm that the bug is gone or still existing?
I don't have the same version installed anymore, but the options window still behaves as described. I'm also not on 2.5.0, but I did my quick check with: A build from r22264M on 2012-09-20 GnuCash 2.4.11 on Ubuntu 12.10 (I'm pretty sure this is the packaged version in the Ubuntu 12.10 repository.) With the memo check-box un-clicked, sometimes the notes check-box is grayed and un-clickable, and sometimes it's not. I should note that I can get it to leave the Notes option UN-GRAYED while I click and un-click the Memo option as well as leave the Notes option GRAYED while I click and un-click the Memo option. I'm not sure if it was behaving like that before or not. Something has changed, however, because I can no longer reproduce the misalignment of columns in the the report. I'll investigate that a bit and reply on the other bug, but as far as it relates to this issue, the inclusion of a column seems to be controlled by the memo check-box regardless of whether or not the notes check-box is behaving properly, and it looks to me like the intended behaviour is to have a separate column on the right for the totals (which is how it worked in this test). I'll try to test on version 2.5.0, but it probably won't be until later this week.
@Carsten: I forgot to ask, is there a specific build version you're using?
I can't reproduce the column mis-alignment but the checkbox bahaviour is definately flaky. Still is in 2.4.12 and 2.5 trunk. Changed staus to new.
GnuCash tells me "built from git rev f6de8e1+". I was following the steps from the Wiki and then did a "git checkout 2.5.0".
*** Bug 724915 has been marked as a duplicate of this bug. ***
I have changed the bug title because this problem is more general than only the Transaction report. And the remainder of the report will focus on the inconsistent behaviour of interdependent options. The column alignment should have been fixed by now (tested with 2.6.9 and current master). I can reproduce the odd option behaviour. And it happens for all options where one option ("master option") controls the active state of one or more other options ("slave options"). Freshly opening a report, and the report options for it, I always follow these precise steps: 1. edit the master option 2. click "Apply" For me the first time I do this, the slave options properly change active state. The second and third time nothing happens. The fourth time it works again and will continue to work until I quit gnucash, regardless of whether I close and reopen the options dialog. While debugging I have found that at some point the function gnc_option_set_selectable in src/app-utils/option-util.c is called for each slave option after changing the master option. When looking at the GNCOptionDB the slave options belong to, I find that for the 2nd and 3rd run the GNCOptionDB is a different pointer from all the other runs (however run 2 and 3 use the same pointer). The 1st, 4th and subsequent runs always use the same pointer to the GNCOptionDB. Unfortunately I'm at a complete loss as to why this is happening. And why only two times ? That's as far as I got until now. Hopefully this extra information will help figure out what is happening. At least there is a workaround: if it fails, try two more times.
I've tested my overhauled Sorting tab with more complicated rules on 2.6.17 Win10 and Win7. It seems to be cycle of approximately 3 master toggles work, 4 master toggles fails, and repeat. Moreover, for complicated toggles, each master toggle seems to keep tally of how many fails before it decides to work :)
Moreover, for complicated toggles, each master toggle seems to keep *its own* tally of how many fails before it decides to work :)
I finally figured it out. On the C side an SCM guile_options object is wrapped in a GNCOptionDB. This is however a multi-to-one relationship. That is there can be several GNCOptionDBs wrapping the same SCM guile_options object. This happens for example when a report is open together with its Options dialog. Both manager their own GNCOptionDB object while both wrap the same SCM guile_options. The problem in this bug was caused by a callback function picking the wrong GNCOptionDB based on the given SCM guile_options object. Which GNCOptionDB got picked was completely dependent on how g_hash_table_foreach would cycle through the stored dbs. It appears this is dependent on the in-memory order of the hash table's values. By being more selective of which GNCOptionDB we're looking for, this could be circumvented. The GNCOptionDB we want is the one related to the open report options dialog. This GNCOptionDB is different from the one managed by the report tab in that it has callbacks set. So from now on we search for a GNCOptionDB that wraps the give SCM guile_options and has one particular callback set. A longer term solution would be to create a one-on-one relationship between GNCOptionDB and SCM guile_options (and even better to handle all options related stuff in C++ and only query it from SCM). I tried to do this now already but it triggers many subtle issues I decided to postpone this work until the Options are rewritten.
Just a smily from me :)
(In reply to Geert Janssens from comment #10) > I finally figured it out. Yay! Good Work! [snip] > A longer term solution would be to create a one-on-one relationship between > GNCOptionDB and SCM guile_options -1 > (and even better to handle all options > related stuff in C++ and only query it from SCM). +1
*** Bug 506151 has been marked as a duplicate of this bug. ***
*** Bug 777386 has been marked as a duplicate of this bug. ***
GnuCash bug tracking has moved to a new Bugzilla host. This bug has been copied to https://bugs.gnucash.org/show_bug.cgi?id=647805. Please update any external references or bookmarks.