When reconciling an account with a lot of transactions, when you scroll down in the reconcile window and then add a new transaction into the account, the reconcile window will reset to the top instead of staying on the currently (or last) selected transaction. This is a regression; this used to happen a long time ago and was fixed, but this bug was re-introduced in the 3.x code base. Steps to reproduce: 1) Start with an account with a lot of unreconciled transactions. 2) Start the reconcile process for that account 3) Scroll down in the reconcile window and select a transaction (or not, it shouldn't matter) 4) Go back to the account register and add a new transaction 5) Notice how the reconcile window scrolled to the top This happens 100% of the time with 3.4 and 3.5 on my FC29 system.
Hi Derek, I'm having a look at this, testing in a current maint built from source on Linux. What I'm seeing is that if you select a split in say the 2nd page of the Funds In panel of the Reconcile window, then use the Open button to go to the register, then add a transaction, when you commit the transaction, the Funds In panel redraws showing nearly the top of the splits (mine shows from the very bottom of the top split). If you scroll down, the correct split is still selected though. Similar happens if you delete a transaction from the register. Is this the problem?
(In reply to Chris Good from comment #1) > Hi Derek, > I'm having a look at this, testing in a current maint built from source on > Linux. > > What I'm seeing is that if you select a split in say the 2nd page of the > Funds In panel of the Reconcile window, then use the Open button to go to > the register, then add a transaction, when you commit the transaction, the > Funds In panel redraws showing nearly the top of the splits (mine shows from > the very bottom of the top split). If you scroll down, the correct split is > still selected though. > > Similar happens if you delete a transaction from the register. > > Is this the problem? Yes, this is the problem (and the regression). In 2.6.x when the pane redrew, the highlighted split would still be in the window. In fact it would not re-scroll the window of splits after the "redraw" at all. IIRC it would anchor the top of the (visible) list.
I haven't been able to trackdown when this regression occurred. It may have been before GnuCash started using Github, in which case I don't know how to track that. I think I'm getting close to knowing enough to attempt a fix, something involving using gtk_tree_view_scroll_to_cell(). In the meantime, a workaround that may help: After adding a transaction, back in the Reconciliation window, Use Down Arrow and it will take you to the next split after the split it was on before the Open button was used.
If you need older Windows packages, they're at https://sourceforge.net/projects/gnucash/files/gnucash%20%28stable%29/ back to 2.2.0.
(In reply to Chris Good from comment #3) > I haven't been able to trackdown when this regression occurred. It may have > been before GnuCash started using Github, in which case I don't know how to > track that. > I think I'm getting close to knowing enough to attempt a fix, something > involving using gtk_tree_view_scroll_to_cell(). > > In the meantime, a workaround that may help: After adding a transaction, > back in the Reconciliation window, Use Down Arrow and it will take you to > the next split after the split it was on before the Open button was used. It happened somewhere between 2.6.x and 3.x. I know that when I was still using 2.6.{latest} that this did not occur, and as soon as I upgraded my desktop and it pulled in 3.x, boom, hit this issue. I believe this coincided with a change of the underlying widget used for the reconcile window lists. I will try the Down-Arrow workaround next time, thanks. I'm surprised I didn't think of that myself! John, I'm not sure whether windows packages will help here?
Derek, I figured that Chris was trying to bisect with the windows setup.exe packages. Why else would he depend on when we started to use Github? It's quite possible that the difference is down to differences between the Gtk2 and Gtk3 implementations of GtkListView. The whole GtkTreeFoo system was thoroughly rewritten for Gtk3. In that case it won't help to find the release with the difference, what's needed is to figure out how to make it do what we want in Gtk3.
Hi John, I was just going thru the commit history for window-reconcile.c, reconcile-view.c and gnc-query-view.c, but I think you're right, we just need to make it work in Gtk3.
Chris, *All* commit history is in git. The old svn revisions have been converted to git commits. So there's no "history from before the move to git". Just a FYI.
I must have forgotten that. :-( thanks Geert.
Created PR# 698 https://github.com/Gnucash/gnucash/pull/698 for maint. I hope everyone in our community is staying safe. :-)
Thanks for help with this John + Geert.
Created new PR# 707 https://github.com/Gnucash/gnucash/pull/707 for master to replace PR 698 (maint).
PR# 707 merged into master 3/5/2020. Fix will be in GC 4.0.
