register position after entering a split

[Fred Bone]

On 7 June 2015 at 18:26, Sean Porterfield said:

> On 06/07/15 17:34, Wm wrote:
> > Sun, 7 Jun 2015 17:04:52 Sean Porterfield
> > 
> >> On 06/07/15 15:15, Wm wrote:
> >>> Sun, 7 Jun 2015 11:51:36 Sean Porterfield
> >>>
> >>>> Is there any rhyme or reason that explains why sometimes adding a
> >>>> transaction positions me to that transaction and other times it stays
> >>>> at the blank at the bottom?
[...]
> I press enter to save the transaction.  Sometimes the blank transaction at
> the bottom is selected, ready for me to enter another transaction.
> Sometimes the transaction I just entered is selected.  That transaction
> (in the examples I'm entering) is old, so the register window has scrolled
> up to display that transaction.
[...]
> My expectation is that after saving a transaction I just added, the
> selected transaction will be the blank one at the bottom.  What causes the
> newly added transaction to be selected sometimes?
> 
> Is that a better question, or have I still failed in wording it properly?
> 
> I have a new theory that has not yet been proved wrong, though I've only
> carefully watched and tested it for about 10 transactions so far.  I
> entered 5 each way and got the same result for all 5.
> 
> I think the case of it scrolling back to the transaction I added is if the
> transaction did not display in balance.  It is in balance - I just didn't
> move my cursor off the last line for it to recalculate and display the
> balanced version.  I thought I would have noticed that before, but it's
> possible I pressed enter before I meant to.  In each of the 5 cases where
> I carefully made sure there was no remaining balance, I was positioned in
> the blank transaction as expected.
> 
> If this theory is correct, it makes perfectly good sense and is a Good
> Thing.  Of course, I also know I've entered some transactions that posted
> to the imbalance or orphan account that I had to fix, but that could be an
> entirely different set of steps that caused the errors. (For a fact on
> several of those I know I pressed enter way too early - having been a
> Quicken user with the "enter = tab" setting in use.) -- Sean Porterfield

I don't think it's anything to do with imbalance, but is the result of 
finalising a txn in split view - regardless of whether there are "extra" 
splits in fact.

If I go to Auto-Split Ledger view before entering a new txn for a past 
date, then when I press Enter the ledger display scrolls back to that 
date (and positions the cursor on the next txn after the just-entered 
one). This happens regardless of whether the txn has two splits (one each 
cr and dr) or more.

The same happens if I leave it in "Basic Ledger" view and use the "Split" 
button at some point while entering the txn.

However, if I go to "Split" view, enter the data, and revert to "Basic" 
view before pressing Enter, the ledger display does not scroll. Again, 
this is true regardless of whether the txn has "extra" splits.

[2.4.12 on WinXPPro-SP3, though I don't expect version or OS have any 
effect on this aspect of its behaviour]