Re: [GNC] Pending Edit Behavior in GnuCash
If there was a way to choose which of existing search windows or General Ledger or 'with sub-accounts ' views to jump to, that would be a plus when jumping. I guess those windows would need better names, esp. for searches . I would like a shortcut back to the a SLR results window or another if there is more than one. David Carlson On Fri, Jun 28, 2019, 12:42 PM David Carlson wrote: > I currently use the jump feature a lot to navigate from the SLR entry list > (a search window) to various account registers to verify context around new > entries, and individual account registers are crucial to monitoring current > balances in asset and liability accounts. > > However, if the jump feature would jump to an individual account register > if the focus is on a split line or to the General Ledger view if in the > description line, I would find that personally acceptable. > > I do not use single line register view or basic ledger view. Since > General Ledger view and search window views do not allow basic ledger view, > that might be an issue for those who like the basic ledger view. > > David Carlson > > On Fri, Jun 28, 2019, 12:07 PM Adrien Monteleone < > adrien.montele...@lusfiber.net> wrote: > >> This is the only reason I ever use the jump button, so I’d be inclined to >> agree. I don’t think I’ve ever jumped just to see the other account. Of >> course, I’m sure others have plenty of use cases. >> >> Regards, >> Adrien >> >> > On Jun 28, 2019, at 11:29 AM, John Ralls wrote: >> > >> > Perhaps that would be a better behavior for the current jump button. >> > >> > Regards, >> > John Ralls >> > >> > >> >> On Jun 28, 2019, at 9:20 AM, David Carlson < >> david.carlson@gmail.com> wrote: >> >> >> >> I would like to throw out a new suggestion to add a permanent menu >> item to >> >> the account register window that would jump to the current transaction >> in >> >> the journal view, where there is no anchor account. This would allow >> >> editing without worrying about whether an anchor account split is being >> >> edited. >> >> >> >> David Carlson >> >> >> >> On Fri, Jun 7, 2019, 9:07 PM Adrien Monteleone < >> >> adrien.montele...@lusfiber.net> wrote: >> >> >> >>> I figured as much, but suggested it anyway at least as a temporary >> >>> workaround. I do see the utility of an edit-only tab. >> >>> >> >>> Regards, >> >>> Adrien >> >>> >> On Jun 7, 2019, at 8:37 PM, David Carlson < >> david.carlson@gmail.com> >> >>> wrote: >> >> Returning to Adrien's comment on my Edit window Suggestion: >> >> >> Finally, I will throw out a radical suggestion that all edits get >> >>> their own >> >> new window instead of happening within a certain register view >> with a >> >> certain "anchor" account which has special behavior compared to >> other >> >>> split >> >> lines. This Edit window would not be tied to any account and >> would be >> >> obviously not saved as long as it exists. >> >> >> > This already exists as the ‘General Journal’ (Tools menu) It’s your >> >>> choice to use it. Though it is not implemented for only the currently >> >>> edited transactions, but the entirety of your data file. >> > >> >> My reasoning for suggesting a dedicated edit window for each >> transaction >> >>> edit is to serve a completely different purpose than that served by >> the >> >>> General Journal, but it may share some code in an implementation. If >> each >> >>> transaction edit was in it's own dedicated window, they would all be >> very >> >>> easy to find and commit or cancel at a later time. Then the possible >> >>> ambiguity of having some pending edits in search windows or the >> General >> >>> Ledger would also be avoided. There may be a better coding technique >> to >> >>> implement this, especially in SQL, so I do not want to be so >> specific to >> >>> prevent the developers from thinking creatively in an implementation. >> >> > David Carlson >> >> >> ___ >> gnucash-user mailing list >> gnucash-user@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. >> > ___ gnucash-user mailing list gnucash-user@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.
Re: [GNC] Pending Edit Behavior in GnuCash
I currently use the jump feature a lot to navigate from the SLR entry list (a search window) to various account registers to verify context around new entries, and individual account registers are crucial to monitoring current balances in asset and liability accounts. However, if the jump feature would jump to an individual account register if the focus is on a split line or to the General Ledger view if in the description line, I would find that personally acceptable. I do not use single line register view or basic ledger view. Since General Ledger view and search window views do not allow basic ledger view, that might be an issue for those who like the basic ledger view. David Carlson On Fri, Jun 28, 2019, 12:07 PM Adrien Monteleone < adrien.montele...@lusfiber.net> wrote: > This is the only reason I ever use the jump button, so I’d be inclined to > agree. I don’t think I’ve ever jumped just to see the other account. Of > course, I’m sure others have plenty of use cases. > > Regards, > Adrien > > > On Jun 28, 2019, at 11:29 AM, John Ralls wrote: > > > > Perhaps that would be a better behavior for the current jump button. > > > > Regards, > > John Ralls > > > > > >> On Jun 28, 2019, at 9:20 AM, David Carlson > wrote: > >> > >> I would like to throw out a new suggestion to add a permanent menu item > to > >> the account register window that would jump to the current transaction > in > >> the journal view, where there is no anchor account. This would allow > >> editing without worrying about whether an anchor account split is being > >> edited. > >> > >> David Carlson > >> > >> On Fri, Jun 7, 2019, 9:07 PM Adrien Monteleone < > >> adrien.montele...@lusfiber.net> wrote: > >> > >>> I figured as much, but suggested it anyway at least as a temporary > >>> workaround. I do see the utility of an edit-only tab. > >>> > >>> Regards, > >>> Adrien > >>> > On Jun 7, 2019, at 8:37 PM, David Carlson < > david.carlson@gmail.com> > >>> wrote: > > Returning to Adrien's comment on my Edit window Suggestion: > > >> Finally, I will throw out a radical suggestion that all edits get > >>> their own > >> new window instead of happening within a certain register view with > a > >> certain "anchor" account which has special behavior compared to > other > >>> split > >> lines. This Edit window would not be tied to any account and would > be > >> obviously not saved as long as it exists. > >> > > This already exists as the ‘General Journal’ (Tools menu) It’s your > >>> choice to use it. Though it is not implemented for only the currently > >>> edited transactions, but the entirety of your data file. > > > > My reasoning for suggesting a dedicated edit window for each > transaction > >>> edit is to serve a completely different purpose than that served by the > >>> General Journal, but it may share some code in an implementation. If > each > >>> transaction edit was in it's own dedicated window, they would all be > very > >>> easy to find and commit or cancel at a later time. Then the possible > >>> ambiguity of having some pending edits in search windows or the General > >>> Ledger would also be avoided. There may be a better coding technique > to > >>> implement this, especially in SQL, so I do not want to be so specific > to > >>> prevent the developers from thinking creatively in an implementation. > > > David Carlson > > > ___ > gnucash-user mailing list > gnucash-user@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. > ___ gnucash-user mailing list gnucash-user@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.
Re: [GNC] Pending Edit Behavior in GnuCash
This is the only reason I ever use the jump button, so I’d be inclined to agree. I don’t think I’ve ever jumped just to see the other account. Of course, I’m sure others have plenty of use cases. Regards, Adrien > On Jun 28, 2019, at 11:29 AM, John Ralls wrote: > > Perhaps that would be a better behavior for the current jump button. > > Regards, > John Ralls > > >> On Jun 28, 2019, at 9:20 AM, David Carlson >> wrote: >> >> I would like to throw out a new suggestion to add a permanent menu item to >> the account register window that would jump to the current transaction in >> the journal view, where there is no anchor account. This would allow >> editing without worrying about whether an anchor account split is being >> edited. >> >> David Carlson >> >> On Fri, Jun 7, 2019, 9:07 PM Adrien Monteleone < >> adrien.montele...@lusfiber.net> wrote: >> >>> I figured as much, but suggested it anyway at least as a temporary >>> workaround. I do see the utility of an edit-only tab. >>> >>> Regards, >>> Adrien >>> On Jun 7, 2019, at 8:37 PM, David Carlson >>> wrote: Returning to Adrien's comment on my Edit window Suggestion: >> Finally, I will throw out a radical suggestion that all edits get >>> their own >> new window instead of happening within a certain register view with a >> certain "anchor" account which has special behavior compared to other >>> split >> lines. This Edit window would not be tied to any account and would be >> obviously not saved as long as it exists. >> > This already exists as the ‘General Journal’ (Tools menu) It’s your >>> choice to use it. Though it is not implemented for only the currently >>> edited transactions, but the entirety of your data file. > My reasoning for suggesting a dedicated edit window for each transaction >>> edit is to serve a completely different purpose than that served by the >>> General Journal, but it may share some code in an implementation. If each >>> transaction edit was in it's own dedicated window, they would all be very >>> easy to find and commit or cancel at a later time. Then the possible >>> ambiguity of having some pending edits in search windows or the General >>> Ledger would also be avoided. There may be a better coding technique to >>> implement this, especially in SQL, so I do not want to be so specific to >>> prevent the developers from thinking creatively in an implementation. > David Carlson ___ gnucash-user mailing list gnucash-user@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.
Re: [GNC] Pending Edit Behavior in GnuCash
Perhaps that would be a better behavior for the current jump button. Regards, John Ralls > On Jun 28, 2019, at 9:20 AM, David Carlson > wrote: > > I would like to throw out a new suggestion to add a permanent menu item to > the account register window that would jump to the current transaction in > the journal view, where there is no anchor account. This would allow > editing without worrying about whether an anchor account split is being > edited. > > David Carlson > > On Fri, Jun 7, 2019, 9:07 PM Adrien Monteleone < > adrien.montele...@lusfiber.net> wrote: > >> I figured as much, but suggested it anyway at least as a temporary >> workaround. I do see the utility of an edit-only tab. >> >> Regards, >> Adrien >> >>> On Jun 7, 2019, at 8:37 PM, David Carlson >> wrote: >>> >>> Returning to Adrien's comment on my Edit window Suggestion: >>> > Finally, I will throw out a radical suggestion that all edits get >> their own > new window instead of happening within a certain register view with a > certain "anchor" account which has special behavior compared to other >> split > lines. This Edit window would not be tied to any account and would be > obviously not saved as long as it exists. > This already exists as the ‘General Journal’ (Tools menu) It’s your >> choice to use it. Though it is not implemented for only the currently >> edited transactions, but the entirety of your data file. >>> >>> My reasoning for suggesting a dedicated edit window for each transaction >> edit is to serve a completely different purpose than that served by the >> General Journal, but it may share some code in an implementation. If each >> transaction edit was in it's own dedicated window, they would all be very >> easy to find and commit or cancel at a later time. Then the possible >> ambiguity of having some pending edits in search windows or the General >> Ledger would also be avoided. There may be a better coding technique to >> implement this, especially in SQL, so I do not want to be so specific to >> prevent the developers from thinking creatively in an implementation. >>> David Carlson >> >> >> ___ >> gnucash-user mailing list >> gnucash-user@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. >> > ___ > gnucash-user mailing list > gnucash-user@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. ___ gnucash-user mailing list gnucash-user@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.
Re: [GNC] Pending Edit Behavior in GnuCash
I would like to throw out a new suggestion to add a permanent menu item to the account register window that would jump to the current transaction in the journal view, where there is no anchor account. This would allow editing without worrying about whether an anchor account split is being edited. David Carlson On Fri, Jun 7, 2019, 9:07 PM Adrien Monteleone < adrien.montele...@lusfiber.net> wrote: > I figured as much, but suggested it anyway at least as a temporary > workaround. I do see the utility of an edit-only tab. > > Regards, > Adrien > > > On Jun 7, 2019, at 8:37 PM, David Carlson > wrote: > > > > Returning to Adrien's comment on my Edit window Suggestion: > > > > >> Finally, I will throw out a radical suggestion that all edits get > their own > > >> new window instead of happening within a certain register view with a > > >> certain "anchor" account which has special behavior compared to other > split > > >> lines. This Edit window would not be tied to any account and would be > > >> obviously not saved as long as it exists. > > >> > > > This already exists as the ‘General Journal’ (Tools menu) It’s your > choice to use it. Though it is not implemented for only the currently > edited transactions, but the entirety of your data file. > > > > > > > My reasoning for suggesting a dedicated edit window for each transaction > edit is to serve a completely different purpose than that served by the > General Journal, but it may share some code in an implementation. If each > transaction edit was in it's own dedicated window, they would all be very > easy to find and commit or cancel at a later time. Then the possible > ambiguity of having some pending edits in search windows or the General > Ledger would also be avoided. There may be a better coding technique to > implement this, especially in SQL, so I do not want to be so specific to > prevent the developers from thinking creatively in an implementation. > > > > > David Carlson > > > ___ > gnucash-user mailing list > gnucash-user@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. > ___ gnucash-user mailing list gnucash-user@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.
Re: [GNC] Pending Edit Behavior in GnuCash
I figured as much, but suggested it anyway at least as a temporary workaround. I do see the utility of an edit-only tab. Regards, Adrien > On Jun 7, 2019, at 8:37 PM, David Carlson wrote: > > Returning to Adrien's comment on my Edit window Suggestion: > > >> Finally, I will throw out a radical suggestion that all edits get their own > >> new window instead of happening within a certain register view with a > >> certain "anchor" account which has special behavior compared to other split > >> lines. This Edit window would not be tied to any account and would be > >> obviously not saved as long as it exists. > >> > > This already exists as the ‘General Journal’ (Tools menu) It’s your choice > > to use it. Though it is not implemented for only the currently edited > > transactions, but the entirety of your data file. > > > > My reasoning for suggesting a dedicated edit window for each transaction edit > is to serve a completely different purpose than that served by the General > Journal, but it may share some code in an implementation. If each > transaction edit was in it's own dedicated window, they would all be very > easy to find and commit or cancel at a later time. Then the possible > ambiguity of having some pending edits in search windows or the General > Ledger would also be avoided. There may be a better coding technique to > implement this, especially in SQL, so I do not want to be so specific to > prevent the developers from thinking creatively in an implementation. > > > David Carlson ___ gnucash-user mailing list gnucash-user@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.
Re: [GNC] Pending Edit Behavior in GnuCash
Returning to Adrien's comment on my Edit window Suggestion: >> Finally, I will throw out a radical suggestion that all edits get their own >> new window instead of happening within a certain register view with a >> certain "anchor" account which has special behavior compared to other split >> lines. This Edit window would not be tied to any account and would be >> obviously not saved as long as it exists. >> > This already exists as the ‘General Journal’ (Tools menu) It’s your choice to use it. Though it is not implemented for only the currently edited transactions, but the entirety of your data file. > My reasoning for suggesting a dedicated edit window for each transaction edit is to serve a completely different purpose than that served by the General Journal, but it may share some code in an implementation. If each transaction edit was in it's own dedicated window, they would all be very easy to find and commit or cancel at a later time. Then the possible ambiguity of having some pending edits in search windows or the General Ledger would also be avoided. There may be a better coding technique to implement this, especially in SQL, so I do not want to be so specific to prevent the developers from thinking creatively in an implementation. > David Carlson > > ___ > gnucash-user mailing list > gnucash-user@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 ___ gnucash-user mailing list gnucash-user@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.
Re: [GNC] Pending Edit Behavior in GnuCash
Making sure all registers have you in the next blank transaction before exiting should also do the trick. Or close them all before saving/exiting. Then if you try to close a register that is being edited, you’ll fire the warning right away and know which one it is. (just a workflow ‘workaround’ mind you, some visual indicator or text in the warning would be nice) Regards, Adrien > On Jun 7, 2019, at 4:40 AM, David Carlson wrote: > >> >> >> 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. > > -- > David Carlson ___ gnucash-user mailing list gnucash-user@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.
Re: [GNC] Pending Edit Behavior in GnuCash
Interesting it is even there. Since there are no amounts and it looks like a dupe, then —delete it? Do the two referenced accounts also show it in their respective registers? Regards, Adrien > On Jun 7, 2019, at 4:36 AM, jeffrey black wrote: > >> > > Thanks. Found it under View->Filter by. > > But; it is giving me the same annoying entry I am getting under other > views as well. There is one extra transaction that is a partial > duplicate of the last real transaction. It has the same date as the > previous valid transaction, no description, has the same funds in > account, no funds out account, and no dollar amounts on either line (not > zero, blank). Gnu-Cash is waiting for me to enter a new transaction > after this one. > > -- > --JEffrey Black M.B.A. > ___ gnucash-user mailing list gnucash-user@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.
Re: [GNC] Pending Edit Behavior in GnuCash
> On Jun 7, 2019, at 2:40 AM, David Carlson wrote: > > > > On Thu, Jun 6, 2019 at 6:25 PM John Ralls wrote: > > > > On Jun 6, 2019, at 1:21 PM, Colin Law wrote: > > > > On Thu, 6 Jun 2019 at 19:04, Adrien Monteleone > > wrote: > >> > >> > >>> On Jun 6, 2019, at 12:40 PM, David Carlson > >>> 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. Yes, it's possible to do that, regardless of backend. Perhaps not a good idea if you typically keep a lot of tabs open and can't keep track of working on more than one transaction at a time. In the SQL backend case you can't force a save so the only way to get the warning is to quit GnuCash or change books (e.g. File>Open). Since at this point you've already forgotten what register you were working in you can also visit each open register in turn and click a transaction other than the one with focus. If the one with focus was being edited you'll get a dialog box. Regards, John Ralls ___ gnucash-user mailing list gnucash-user@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.
Re: [GNC] Pending Edit Behavior in GnuCash
On Thu, Jun 6, 2019 at 6:25 PM John Ralls wrote: > > > > On Jun 6, 2019, at 1:21 PM, Colin Law wrote: > > > > On Thu, 6 Jun 2019 at 19:04, Adrien Monteleone > > wrote: > >> > >> > >>> On Jun 6, 2019, at 12:40 PM, David Carlson < > david.carlson@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@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 ___ gnucash-user mailing list gnucash-user@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.
Re: [GNC] Pending Edit Behavior in GnuCash
On 6/7/2019 4:06 AM, Adrien Monteleone wrote: > >> On Jun 7, 2019, at 3:57 AM, jeffrey black wrote: >> >> I think I missed something here Adrien. I only get a /months worth /of >> transactions in a tab across some but not all accounts which have >> entries. What am I not setting right in preferences? (Windoze 10 => >> Version: 3.5 Build ID: 3.5+(2019-03-30) Finance::Quote: -) >> >> -- >> --JEffrey Black M.B.A. > Check Edit > Filter By... > > The General Journal defaults to a 30 day window if I’m not mistaken. (mine > was set as such) Unfortunately, I don’t think there is a preference to set > this. You have to change it each time you open it. > > Be sure to check the other Filter tab as well to make sure you are seeing all > transactions you want to see. (personally, I’d think the Journal should show > everything, but that’s just me) > > My understanding is that one or the other (individual account registers, or > General Journal) is ‘virtual’ while the other is how the data is actually > stored. Traditional accounting would use the Journal first, but I seem to > recall reading that GnuCash does this in reverse. > > Regards, > Adrien > ___ > gnucash-user mailing list > gnucash-user@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. Thanks. Found it under View->Filter by. But; it is giving me the same annoying entry I am getting under other views as well. There is one extra transaction that is a partial duplicate of the last real transaction. It has the same date as the previous valid transaction, no description, has the same funds in account, no funds out account, and no dollar amounts on either line (not zero, blank). Gnu-Cash is waiting for me to enter a new transaction after this one. -- --JEffrey Black M.B.A. ___ gnucash-user mailing list gnucash-user@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.
Re: [GNC] Pending Edit Behavior in GnuCash
Op vrijdag 7 juni 2019 11:06:28 CEST schreef Adrien Monteleone: > > On Jun 7, 2019, at 3:57 AM, jeffrey black > > wrote: > > > > > > I think I missed something here Adrien. I only get a /months worth /of > > transactions in a tab across some but not all accounts which have > > entries. What am I not setting right in preferences? (Windoze 10 => > > Version: 3.5 Build ID: 3.5+(2019-03-30) Finance::Quote: -) > > Check Edit > Filter By... > > The General Journal defaults to a 30 day window if I’m not mistaken. (mine > was set as such) Unfortunately, I don’t think there is a preference to set > this. You have to change it each time you open it. > Recent versions of GnuCash allow you to save your preference, even for the General Journal. This was implemented by Robert Fewell somewhere in the 3.x series. Geert ___ gnucash-user mailing list gnucash-user@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.
Re: [GNC] Pending Edit Behavior in GnuCash
> On Jun 7, 2019, at 3:57 AM, jeffrey black wrote: > >> > I think I missed something here Adrien. I only get a /months worth /of > transactions in a tab across some but not all accounts which have > entries. What am I not setting right in preferences? (Windoze 10 => > Version: 3.5 Build ID: 3.5+(2019-03-30) Finance::Quote: -) > > -- > --JEffrey Black M.B.A. Check Edit > Filter By... The General Journal defaults to a 30 day window if I’m not mistaken. (mine was set as such) Unfortunately, I don’t think there is a preference to set this. You have to change it each time you open it. Be sure to check the other Filter tab as well to make sure you are seeing all transactions you want to see. (personally, I’d think the Journal should show everything, but that’s just me) My understanding is that one or the other (individual account registers, or General Journal) is ‘virtual’ while the other is how the data is actually stored. Traditional accounting would use the Journal first, but I seem to recall reading that GnuCash does this in reverse. Regards, Adrien ___ gnucash-user mailing list gnucash-user@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.
Re: [GNC] Pending Edit Behavior in GnuCash
On 6/5/2019 4:51 PM, Adrien Monteleone wrote: > >> GnuCash, at least in the 2.6.xx series usually prohibits leaving a >> transaction that contains pending edits without using the Enter key to >> commit the edits, but it has some exceptions which set up some difficult >> situations when finally trying to do a manual File > Save. At that point >> it asks if you want to save edits in some register view which may even be >> accidental edits or keystrokes that would delete desired data. >> >> The most common action (for me) that sets this up is to start an edit in >> some register then navigate to another register without first saving the >> pending edit. This easily happens if the user is reviewing results from >> the Since Last Run assistant especially if a cat crosses the keyboard. > Using Sqlite backend, of course I get instant saves so I don’t see this issue > anymore, but that sort of ambiguous ’save edits’ question is disconcerting if > you are pretty sure you’ve committed all transactions, and now you’re being > told you haven’t. > >> I can see the reasoning that often users may need to view other registers >> to compare the transaction currently being edited to something else, so I >> do not want to prevent that. I would propose that the tabs containing >> pending edits flash in some way to catch the user's attention so he can >> find his way back to see if it was cat-tracks or a real pending edit. > Interesting idea. Though this might interfere with the custom tab colors, I > like the idea of some visual indicator that something has been edited and > needs attention. (perhaps a bold or italic typeface change?) Flashing however > I would not be in favor of. I don't use the SQL back-end because of the lack of a rollback feature. I frequently, much to often, make mistakes on import matching, wrong account match, etc. And some recent crashes have created something of a nightmare for me (the xml file is shall we say much more user friendly in that regard). Windoze 10 is not exactly stable, it crashes on Micro$oft's own programs. (wish list: the Ubuntu repositories provide the latest version. My attempts at building have failed miserably. My tower typically runs Windoze 10 while my networked laptop runs Ubuntu. For whatever reason that is the only combination of OS's that I can get to cooperate over my network. I suspect it is a router incompatibility but; that is my problem not the teams.) I frequently get the message box of save or cancel the changed transaction. What transaction, I have not edited or started one. And Gnu-Cash does not show me where or which transaction has been changed. An indicator of the account which has been altered transaction and taking me back to the transaction would be a godsend. I agree a flashing account tab would not be aesthetic. Perhaps a scrolling color change for the account tab but; at least take me back to the offending transaction so I can see if I am accepting or canceling a mistake or not. > >> Finally, I will throw out a radical suggestion that all edits get their own >> new window instead of happening within a certain register view with a >> certain "anchor" account which has special behavior compared to other split >> lines. This Edit window would not be tied to any account and would be >> obviously not saved as long as it exists. >> > This already exists as the ‘General Journal’ (Tools menu) It’s your choice to > use it. Though it is not implemented for only the currently edited > transactions, but the entirety of your data file. > > Regards, > Adrien I think I missed something here Adrien. I only get a /months worth /of transactions in a tab across some but not all accounts which have entries. What am I not setting right in preferences? (Windoze 10 => Version: 3.5 Build ID: 3.5+(2019-03-30) Finance::Quote: -) -- --JEffrey Black M.B.A. > ___ > gnucash-user mailing list > gnucash-user@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. ___ gnucash-user mailing list gnucash-user@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.
Re: [GNC] Pending Edit Behavior in GnuCash
> On Jun 6, 2019, at 1:21 PM, Colin Law wrote: > > On Thu, 6 Jun 2019 at 19:04, Adrien Monteleone > wrote: >> >> >>> On Jun 6, 2019, at 12:40 PM, David Carlson >>> 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. Regards, John Ralls ___ gnucash-user mailing list gnucash-user@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.
Re: [GNC] Pending Edit Behavior in GnuCash
On Thu, 6 Jun 2019 at 19:04, Adrien Monteleone wrote: > > > > On Jun 6, 2019, at 12:40 PM, David Carlson > > 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. Colin ___ gnucash-user mailing list gnucash-user@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.
Re: [GNC] Pending Edit Behavior in GnuCash
> On Jun 6, 2019, at 12:40 PM, David Carlson > 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) > > 2. Regarding flashing tabs. I do admit that I do not recall seeing anything > similar lately in other applications, but I would think that if they flash as > slowly as the curser does or even slower and without excessive brightness or > contrast they would be OK. Why don't you like flashing? Personally my aversion to flashing things is from the early days of the web where people thought that just because they *could* make text flash and graphics move, that they *should*. It was ubiquitous for a spell and it drove me nuts. (such behavior is listed as a major faux pas on webpagesthatsuck.com) But I’ve since come to be made aware that as a visual indicator it isn’t the best method. For accessibility reasons, some people don’t perceive different flashing rates the same, or even some rates at all. And some rates are potentially dangerous to use for people who can have neurological responses triggered by the flashing. Since there is no consistent flashing rate that is both ’safe’ and ‘effective’ for all, it is best not to use it. For some reason, I’m so used to blinking cursors they don’t bother me. But that too is configurable for those that don’t like it, can’t see it well, or health reasons. Since I usually keep GC open and wouldn’t likely trigger the flashing, I’m not going to file a bug on it should be implemented, but I wouldn’t be surprised to see one or more pop up, or at least have some complaints on the mailing lists. I suggested the bold/italic method based on my experience with e-mail clients that might use bold to indicate a folder with unread messages, and other apps (can’t think of specific ones at the moment) that use italics to indicate changed data that hasn’t been saved. Either or both would be good visual indicators that the user can easily spot with or without the warning dialog when exiting. I can even see the utility of an overriding text/background color but consideration here would have to take into account that users (like myself) set their own CSS files. So providing styling hooks for those alterations would be helpful in case the choice of color is the same already being used for other purposes. Regards, Adrien ___ gnucash-user mailing list gnucash-user@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.
Re: [GNC] Pending Edit Behavior in GnuCash
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? 2. Regarding flashing tabs. I do admit that I do not recall seeing anything similar lately in other applications, but I would think that if they flash as slowly as the curser does or even slower and without excessive brightness or contrast they would be OK. Why don't you like flashing? David Carlson On Wed, Jun 5, 2019 at 6:37 PM Adrien Monteleone < adrien.montele...@lusfiber.net> wrote: > Thanks, I forgot about those methods. > > Regards, > Adrien > > > On Jun 5, 2019, at 5:35 PM, John Ralls wrote: > > > > There's also cutting, using either ctrl/cmd-X or Edit>Cut Split? > > > > https://bugs.gnucash.org/show_bug.cgi?id=797249 > > https://github.com/Gnucash/gnucash/pull/517 > > > > Regards, > > John Ralls > > > > ___ > gnucash-user mailing list > gnucash-user@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 ___ gnucash-user mailing list gnucash-user@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.
Re: [GNC] Pending Edit Behavior in GnuCash
Thanks, I forgot about those methods. Regards, Adrien > On Jun 5, 2019, at 5:35 PM, John Ralls wrote: > > There's also cutting, using either ctrl/cmd-X or Edit>Cut Split? > > https://bugs.gnucash.org/show_bug.cgi?id=797249 > https://github.com/Gnucash/gnucash/pull/517 > > Regards, > John Ralls > ___ gnucash-user mailing list gnucash-user@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.
Re: [GNC] Pending Edit Behavior in GnuCash
It appears this bug has already been filed: https://bugs.gnucash.org/show_bug.cgi?id=797249 (at least with respect to the inconsistent behavior based on method used. Not blowing up the currently edited transaction is considered a major behavior change, personally I’d prefer the warning appear and be given the option to proceed without deleting the anchor split, or deleting the entire transaction, not just having it vaporize on me.) Regards, Adrien > On Jun 5, 2019, at 5:04 PM, Adrien Monteleone > wrote: > > Update on the bug. > > I just tested this under the following circumstance: > > 1. I started entering a transaction with a description that produced an > auto-fill of several splits. > 2. The auto-fill contained 2 splits anchoring to the current register. > 3. Attempting to right-click and ‘delete split’, using the toolbar button, or > using the Transaction > Delete Split menu entry on the 1st anchoring split > fired the warning and told me I *cannot* delete this split. My only choice > was to accept this, leave the split in place and proceed. > 4. Attempting to delete the second anchoring split, by either means, was > successful, without warning, and without blowing up the transaction, because > there was a previous anchoring split still tying it to the current register - > results as expected. > > I also tested a fresh transaction with a new description and deleted the > anchor split. It erased the transaction completely. Perhaps it should either > still fire the warning, or at least leave you editing the transaction without > deleting date/num/description/notes, et cetera until you hit Enter to commit. > > Finally, I tested entering another split into a fresh transaction, without > putting any memo or amount on the anchoring split. When I tried to delete the > anchoring split, I received the warning and was not allowed to delete it. > > So it seems the last of the inconsistent behavior is when entering a fresh > transaction and trying to delete the anchor split before entering other > splits. I’ll file a bug on this shortly. > > Regards, > Adrien > >> On Jun 5, 2019, at 4:51 PM, Adrien Monteleone >> wrote: >> >> >> >>> On Jun 5, 2019, at 3:06 PM, David Carlson >>> wrote: >>> >>> I might as well get this debate started now. Another thread has started a >>> discussion about unsplitting transactions, pointing out that there is an >>> inconsistency between using the various Transaction > [edit] Split keys >>> and the conventional keystroke editing method using the Tab key to navigate >>> around a transaction. >>> I think there should be a warning for any editing action that deletes a >>> split line, including tabbing off the anchor line. Obviously, edits to >>> correct account assignment errors must be allowed and not be overly >>> encumbered by unnecessary warnings. >>> >> >> David, >> >> As I recently (a few minutes ago) noted in that other thread, this is >> allegedly fixed as of 3.4. (https://bugs.gnucash.org/show_bug.cgi?id=796978) >> Perhaps the commit didn’t work as expected. I’m getting ready to test it. >> >> >>> GnuCash, at least in the 2.6.xx series usually prohibits leaving a >>> transaction that contains pending edits without using the Enter key to >>> commit the edits, but it has some exceptions which set up some difficult >>> situations when finally trying to do a manual File > Save. At that point >>> it asks if you want to save edits in some register view which may even be >>> accidental edits or keystrokes that would delete desired data. >>> >>> The most common action (for me) that sets this up is to start an edit in >>> some register then navigate to another register without first saving the >>> pending edit. This easily happens if the user is reviewing results from >>> the Since Last Run assistant especially if a cat crosses the keyboard. >> >> Using Sqlite backend, of course I get instant saves so I don’t see this >> issue anymore, but that sort of ambiguous ’save edits’ question is >> disconcerting if you are pretty sure you’ve committed all transactions, and >> now you’re being told you haven’t. >> >>> >>> I can see the reasoning that often users may need to view other registers >>> to compare the transaction currently being edited to something else, so I >>> do not want to prevent that. I would propose that the tabs containing >>> pending edits flash in some way to catch the user's attention so he can >>> find his way back to see if it was cat-tracks or a real pending edit. >> >> Interesting idea. Though this might interfere with the custom tab colors, I >> like the idea of some visual indicator that something has been edited and >> needs attention. (perhaps a bold or italic typeface change?) Flashing >> however I would not be in favor of. >> >>> >>> There are also a couple of cases where attempting to cancel a pending edit >>> does not correctly restore the transaction to the previous state which >>> could be fixed
Re: [GNC] Pending Edit Behavior in GnuCash
There's also cutting, using either ctrl/cmd-X or Edit>Cut Split? https://bugs.gnucash.org/show_bug.cgi?id=797249 https://github.com/Gnucash/gnucash/pull/517 Regards, John Ralls > On Jun 5, 2019, at 3:04 PM, Adrien Monteleone > wrote: > > Update on the bug. > > I just tested this under the following circumstance: > > 1. I started entering a transaction with a description that produced an > auto-fill of several splits. > 2. The auto-fill contained 2 splits anchoring to the current register. > 3. Attempting to right-click and ‘delete split’, using the toolbar button, or > using the Transaction > Delete Split menu entry on the 1st anchoring split > fired the warning and told me I *cannot* delete this split. My only choice > was to accept this, leave the split in place and proceed. > 4. Attempting to delete the second anchoring split, by either means, was > successful, without warning, and without blowing up the transaction, because > there was a previous anchoring split still tying it to the current register - > results as expected. > > I also tested a fresh transaction with a new description and deleted the > anchor split. It erased the transaction completely. Perhaps it should either > still fire the warning, or at least leave you editing the transaction without > deleting date/num/description/notes, et cetera until you hit Enter to commit. > > Finally, I tested entering another split into a fresh transaction, without > putting any memo or amount on the anchoring split. When I tried to delete the > anchoring split, I received the warning and was not allowed to delete it. > > So it seems the last of the inconsistent behavior is when entering a fresh > transaction and trying to delete the anchor split before entering other > splits. I’ll file a bug on this shortly. > > Regards, > Adrien > >> On Jun 5, 2019, at 4:51 PM, Adrien Monteleone >> wrote: >> >> >> >>> On Jun 5, 2019, at 3:06 PM, David Carlson >>> wrote: >>> >>> I might as well get this debate started now. Another thread has started a >>> discussion about unsplitting transactions, pointing out that there is an >>> inconsistency between using the various Transaction > [edit] Split keys >>> and the conventional keystroke editing method using the Tab key to navigate >>> around a transaction. >>> I think there should be a warning for any editing action that deletes a >>> split line, including tabbing off the anchor line. Obviously, edits to >>> correct account assignment errors must be allowed and not be overly >>> encumbered by unnecessary warnings. >>> >> >> David, >> >> As I recently (a few minutes ago) noted in that other thread, this is >> allegedly fixed as of 3.4. (https://bugs.gnucash.org/show_bug.cgi?id=796978) >> Perhaps the commit didn’t work as expected. I’m getting ready to test it. >> >> >>> GnuCash, at least in the 2.6.xx series usually prohibits leaving a >>> transaction that contains pending edits without using the Enter key to >>> commit the edits, but it has some exceptions which set up some difficult >>> situations when finally trying to do a manual File > Save. At that point >>> it asks if you want to save edits in some register view which may even be >>> accidental edits or keystrokes that would delete desired data. >>> >>> The most common action (for me) that sets this up is to start an edit in >>> some register then navigate to another register without first saving the >>> pending edit. This easily happens if the user is reviewing results from >>> the Since Last Run assistant especially if a cat crosses the keyboard. >> >> Using Sqlite backend, of course I get instant saves so I don’t see this >> issue anymore, but that sort of ambiguous ’save edits’ question is >> disconcerting if you are pretty sure you’ve committed all transactions, and >> now you’re being told you haven’t. >> >>> >>> I can see the reasoning that often users may need to view other registers >>> to compare the transaction currently being edited to something else, so I >>> do not want to prevent that. I would propose that the tabs containing >>> pending edits flash in some way to catch the user's attention so he can >>> find his way back to see if it was cat-tracks or a real pending edit. >> >> Interesting idea. Though this might interfere with the custom tab colors, I >> like the idea of some visual indicator that something has been edited and >> needs attention. (perhaps a bold or italic typeface change?) Flashing >> however I would not be in favor of. >> >>> >>> There are also a couple of cases where attempting to cancel a pending edit >>> does not correctly restore the transaction to the previous state which >>> could be fixed at the same time other pending edit behavior is addressed. >> >> Sounds like a bug. >>> >>> Another situation where pending edit behavior is inconsistent is when >>> editing scheduled transactions, the Enter key may or may not save the edit, >>> depending on which field the fo
Re: [GNC] Pending Edit Behavior in GnuCash
Update on the bug. I just tested this under the following circumstance: 1. I started entering a transaction with a description that produced an auto-fill of several splits. 2. The auto-fill contained 2 splits anchoring to the current register. 3. Attempting to right-click and ‘delete split’, using the toolbar button, or using the Transaction > Delete Split menu entry on the 1st anchoring split fired the warning and told me I *cannot* delete this split. My only choice was to accept this, leave the split in place and proceed. 4. Attempting to delete the second anchoring split, by either means, was successful, without warning, and without blowing up the transaction, because there was a previous anchoring split still tying it to the current register - results as expected. I also tested a fresh transaction with a new description and deleted the anchor split. It erased the transaction completely. Perhaps it should either still fire the warning, or at least leave you editing the transaction without deleting date/num/description/notes, et cetera until you hit Enter to commit. Finally, I tested entering another split into a fresh transaction, without putting any memo or amount on the anchoring split. When I tried to delete the anchoring split, I received the warning and was not allowed to delete it. So it seems the last of the inconsistent behavior is when entering a fresh transaction and trying to delete the anchor split before entering other splits. I’ll file a bug on this shortly. Regards, Adrien > On Jun 5, 2019, at 4:51 PM, Adrien Monteleone > wrote: > > > >> On Jun 5, 2019, at 3:06 PM, David Carlson >> wrote: >> >> I might as well get this debate started now. Another thread has started a >> discussion about unsplitting transactions, pointing out that there is an >> inconsistency between using the various Transaction > [edit] Split keys >> and the conventional keystroke editing method using the Tab key to navigate >> around a transaction. >> I think there should be a warning for any editing action that deletes a >> split line, including tabbing off the anchor line. Obviously, edits to >> correct account assignment errors must be allowed and not be overly >> encumbered by unnecessary warnings. >> > > David, > > As I recently (a few minutes ago) noted in that other thread, this is > allegedly fixed as of 3.4. (https://bugs.gnucash.org/show_bug.cgi?id=796978) > Perhaps the commit didn’t work as expected. I’m getting ready to test it. > > >> GnuCash, at least in the 2.6.xx series usually prohibits leaving a >> transaction that contains pending edits without using the Enter key to >> commit the edits, but it has some exceptions which set up some difficult >> situations when finally trying to do a manual File > Save. At that point >> it asks if you want to save edits in some register view which may even be >> accidental edits or keystrokes that would delete desired data. >> >> The most common action (for me) that sets this up is to start an edit in >> some register then navigate to another register without first saving the >> pending edit. This easily happens if the user is reviewing results from >> the Since Last Run assistant especially if a cat crosses the keyboard. > > Using Sqlite backend, of course I get instant saves so I don’t see this issue > anymore, but that sort of ambiguous ’save edits’ question is disconcerting if > you are pretty sure you’ve committed all transactions, and now you’re being > told you haven’t. > >> >> I can see the reasoning that often users may need to view other registers >> to compare the transaction currently being edited to something else, so I >> do not want to prevent that. I would propose that the tabs containing >> pending edits flash in some way to catch the user's attention so he can >> find his way back to see if it was cat-tracks or a real pending edit. > > Interesting idea. Though this might interfere with the custom tab colors, I > like the idea of some visual indicator that something has been edited and > needs attention. (perhaps a bold or italic typeface change?) Flashing however > I would not be in favor of. > >> >> There are also a couple of cases where attempting to cancel a pending edit >> does not correctly restore the transaction to the previous state which >> could be fixed at the same time other pending edit behavior is addressed. > > Sounds like a bug. >> >> Another situation where pending edit behavior is inconsistent is when >> editing scheduled transactions, the Enter key may or may not save the edit, >> depending on which field the focus happens to be in. I think that the >> enter key should always save pending edits. > > Again, I’d think a bug. I would expect Enter to always commit an edit. > (especially since the Help manual says as much, or so I recall last time I > read it) >> >> Finally, I will throw out a radical suggestion that all edits get their own >> new window instead of happening w
Re: [GNC] Pending Edit Behavior in GnuCash
> On Jun 5, 2019, at 3:06 PM, David Carlson wrote: > > I might as well get this debate started now. Another thread has started a > discussion about unsplitting transactions, pointing out that there is an > inconsistency between using the various Transaction > [edit] Split keys > and the conventional keystroke editing method using the Tab key to navigate > around a transaction. > I think there should be a warning for any editing action that deletes a > split line, including tabbing off the anchor line. Obviously, edits to > correct account assignment errors must be allowed and not be overly > encumbered by unnecessary warnings. > David, As I recently (a few minutes ago) noted in that other thread, this is allegedly fixed as of 3.4. (https://bugs.gnucash.org/show_bug.cgi?id=796978) Perhaps the commit didn’t work as expected. I’m getting ready to test it. > GnuCash, at least in the 2.6.xx series usually prohibits leaving a > transaction that contains pending edits without using the Enter key to > commit the edits, but it has some exceptions which set up some difficult > situations when finally trying to do a manual File > Save. At that point > it asks if you want to save edits in some register view which may even be > accidental edits or keystrokes that would delete desired data. > > The most common action (for me) that sets this up is to start an edit in > some register then navigate to another register without first saving the > pending edit. This easily happens if the user is reviewing results from > the Since Last Run assistant especially if a cat crosses the keyboard. Using Sqlite backend, of course I get instant saves so I don’t see this issue anymore, but that sort of ambiguous ’save edits’ question is disconcerting if you are pretty sure you’ve committed all transactions, and now you’re being told you haven’t. > > I can see the reasoning that often users may need to view other registers > to compare the transaction currently being edited to something else, so I > do not want to prevent that. I would propose that the tabs containing > pending edits flash in some way to catch the user's attention so he can > find his way back to see if it was cat-tracks or a real pending edit. Interesting idea. Though this might interfere with the custom tab colors, I like the idea of some visual indicator that something has been edited and needs attention. (perhaps a bold or italic typeface change?) Flashing however I would not be in favor of. > > There are also a couple of cases where attempting to cancel a pending edit > does not correctly restore the transaction to the previous state which > could be fixed at the same time other pending edit behavior is addressed. Sounds like a bug. > > Another situation where pending edit behavior is inconsistent is when > editing scheduled transactions, the Enter key may or may not save the edit, > depending on which field the focus happens to be in. I think that the > enter key should always save pending edits. Again, I’d think a bug. I would expect Enter to always commit an edit. (especially since the Help manual says as much, or so I recall last time I read it) > > Finally, I will throw out a radical suggestion that all edits get their own > new window instead of happening within a certain register view with a > certain "anchor" account which has special behavior compared to other split > lines. This Edit window would not be tied to any account and would be > obviously not saved as long as it exists. > This already exists as the ‘General Journal’ (Tools menu) It’s your choice to use it. Though it is not implemented for only the currently edited transactions, but the entirety of your data file. Regards, Adrien ___ gnucash-user mailing list gnucash-user@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.
