[GNC] Pending Edit Behavior in GnuCash

David Carlson david.carlson.417 at gmail.com
Fri Jun 7 05:40:12 EDT 2019


On Thu, Jun 6, 2019 at 6:25 PM John Ralls <jralls at ceridwen.us> wrote:

>
>
> > On Jun 6, 2019, at 1:21 PM, Colin Law <clanlaw at gmail.com> wrote:
> >
> > On Thu, 6 Jun 2019 at 19:04, Adrien Monteleone
> > <adrien.monteleone at lusfiber.net> wrote:
> >>
> >>
> >>> On Jun 6, 2019, at 12:40 PM, David Carlson <
> david.carlson.417 at gmail.com> wrote:
> >>>
> >>> Adrien,
> >>>
> >>> Looking at your comments, I have two questions.
> >>>
> >>> 1. Does SQLite not allow pending edits at all? or is it after every
> keystroke?  How do you avoid accidental deletions?
> >>
> >> Not sure specifically what you mean by ‘pending edits'. I think writes
> are supposed to be instant, but I haven’t tested exactly how ‘instant’ —as
> by keystroke, Tab, or Enter as a commit. I don’t know that I’ve
> accidentally deleted something critical, certainly not an entire
> transaction. I might have inadvertently changed an account assignment to
> something I didn’t want, or selected an entire memo and deleted it when I
> only wanted to delete a portion of it, but that is an easy fix, especially
> as I’ll notice it immediately. (I wish CMD-Z ‘undo’ worked though - since
> it doesn’t, perhaps writes are by keystroke?) As long as the app is still
> open, I just make any changes I need. I’m not prevented from doing so. (I
> also keep the app open 24/7 and only close to do an update of GC itself, or
> the OS)
> >
> > I believe the transaction is not saved until you hit that last Enter
> > key to do it.  There is, after all, a Cancel button at the top that
> > allows one to revert the transaction being edited back to what it was
> > originally.
>
> Mostly right: Committing the edit immediately generates a database update.
> If it's editing an object with a dialog box (including transactions with
> the Transfer Dialog) then clicking the OK button commits. For transactions
> in the register, it's hitting Enter, tabbing off the end, or clicking on a
> different transaction and then confirming the edit in the message box.
>
> Does this mean that it is still possible in a SQLite database to start a
transaction edit, then, without committing it, navigate to another account
register and edit another transaction?  If so, when does the first
transaction edit finally get committed?  The difficulty with finding those
un-committed edits in the XML data version is the reason for my 'blinking'
proposal.

The method that I currently use is to start a manual File  > Save, then, if
there is a pop-up indicating a need to save or cancel an edit, try to guess
which tab I need to look under for the offending edit,  When I think I have
the right tab, press the Tab key to see if I am in the un-committed
transaction.  If the warning re-appears, I am there.  If not, maybe it is
in another tab, perhaps a search tab.  This is hardly efficient.

It would also be helpful if any transaction edit action somehow changed the
appearance of that transaction so that the need to commit is more obvious.


> Regards,
> John Ralls
>
> _______________________________________________
> gnucash-user mailing list
> gnucash-user at gnucash.org
> To update your subscription preferences or to unsubscribe:
> https://lists.gnucash.org/mailman/listinfo/gnucash-user
> If you are using Nabble or Gmane, please see
> https://wiki.gnucash.org/wiki/Mailing_Lists for more information.
> -----
> Please remember to CC this list on all your replies.
> You can do this by using Reply-To-List or Reply-All.
>


-- 
David Carlson


More information about the gnucash-user mailing list