After an evaluation, GNOME has moved from Bugzilla to GitLab. Learn more about GitLab.
No new issues can be reported in GNOME Bugzilla anymore.
To report an issue in a GNOME project, go to GNOME GitLab.
Do not go to GNOME Gitlab for: Bluefish, Doxygen, GnuCash, GStreamer, java-gnome, LDTP, NetworkManager, Tomboy.
Bug 698899 - Register to Treeview - Scheduler and some fixes for leaks
Register to Treeview - Scheduler and some fixes for leaks
Status: RESOLVED FIXED
Product: GnuCash
Classification: Other
Component: Register
2.5.x
Other Linux
: Normal enhancement
: ---
Assigned To: Christian Stimming
Geert Janssens
Depends on:
Blocks: 673193
 
 
Reported: 2013-04-25 21:21 UTC by Bob
Modified: 2018-06-29 23:15 UTC
See Also:
GNOME target: ---
GNOME version: ---


Attachments
Register patch 19 (196.06 KB, patch)
2013-04-25 21:21 UTC, Bob
committed Details | Review
Schedule Patch (4.43 KB, patch)
2013-04-25 21:24 UTC, Bob
committed Details | Review
Register patch 20 (163.61 KB, patch)
2013-04-25 21:26 UTC, Bob
committed Details | Review
Screenshot illustrating sx editing error message (68.21 KB, image/png)
2013-05-02 15:13 UTC, Geert Janssens
  Details

Description Bob 2013-04-25 21:21:26 UTC
Created attachment 242470 [details] [review]
Register patch 19

This is an update to the Possible Register migration to Treeview - 673193

Register rewrite Update, this adds the schedule option with some other changes.

This update adds the schedule option. The schedule editor files have been duplicated and used to edit the schedule with the template displaying in the tree view. This is accessed from additional menu options on the Scheduled Transactions plugin page under Schedule, New 2 and Edit 2.

Other changes are to the date renderer, FuturePostedDate function, fix the split collapse option and move some functions around.
Comment 1 Bob 2013-04-25 21:24:55 UTC
Created attachment 242471 [details] [review]
Schedule Patch

Whilst testing the changes in the schedule, I found I could schedule a share purchase just like a currency transaction but when on the sinse last run dialog, both allowed me to specify the price/rate but only the currency transaction would get added using the specified value. This patch fixes this. I have tested this and it looks OK to me but needs verifying.
Comment 2 Bob 2013-04-25 21:26:25 UTC
Created attachment 242473 [details] [review]
Register patch 20

This patch fixes some memory leaks and renames some functions to a standard format.
Comment 3 Geert Janssens 2013-05-02 15:04:29 UTC
Comment on attachment 242470 [details] [review]
Register patch 19

Committed, thank you very much.
Comment 4 Geert Janssens 2013-05-02 15:11:36 UTC
Comment on attachment 242471 [details] [review]
Schedule Patch

Committed, thank you very much.

There is a small issue though with either this or the previous patch:

- I open an existing sx
- I use Edit2 to edit the transaction
- Then I go to the transaction details tab
- Without changing anyting, I hit "Ok"

=> This pops up an error dialog with this message:
Couldn't parse credit formula for split "".

I will attach a screenshot to illustrate the issue.
Comment 5 Geert Janssens 2013-05-02 15:12:39 UTC
Comment on attachment 242473 [details] [review]
Register patch 20

Committed, thank you very much.
Comment 6 Geert Janssens 2013-05-02 15:13:25 UTC
Created attachment 243067 [details]
Screenshot illustrating sx editing error message
Comment 7 Geert Janssens 2013-05-02 15:16:21 UTC
Lastly, I'm not sure when this started, but using the old registers instead of the new registers now spews lots of these:
CRIT <gnc.engine> xaccAccountGetType: assertion `GNC_IS_ACCOUNT(acc)' failed

I suspect it has to do with the empty split line, because I see it appearing most when hovering/clicking this line, or when it is scrolled into view.

I'm not sure though if it's still worth fixing this as the old register is on the way out...
Comment 8 Bob 2013-05-02 17:52:53 UTC
(In reply to comment #4)

Just had a quick look and it does not like the numbers, if I change an entry to the same as you, I get the same message as you do as well as in the old one. I will try and start my Gnucash in your local to prove.
Comment 9 Geert Janssens 2013-05-03 12:26:13 UTC
A locale issue would be my first guess.

It is an old, unfortunate design decision to store the transaction formulas with numbers in the locale format. In my locale (nl_BE if you want to test), one thousand is represented as 1.000,00. If I change my locale to en_US, I get parsing errors on the SX.

However, the original SX code works fine if I stay in my locale, but the new SX code seems to have issues with this.

If you can come up with a proper long-term solution for this, that would be great, though it's not required to be part of the register rewrite. There already exists an old bugreport for this: bug 370331.
Comment 10 Bob 2013-05-03 18:32:04 UTC
I do not get this, if I start gnucash with the following line LANGUAGE=nl_BE LANG=nl_BE LC_MONETARY=nl_BE gnucash it starts up and I create a new file. Add some entries, and then use one to create a schedule from and this can be seen in the editor, both the old and new one with out any problem. Yes if I then open the same file with UK settings, it fails to parse but in both old and new editor which is what I would expect which implies above.

With that startup line my numbers are '10 000,00' format !!

Would it be possible for you to create a new file, do the above and attach or tell me where I am going wrong.

Regards,

  Bob
Comment 11 Geert Janssens 2013-05-04 16:49:39 UTC
It turns out to be effectively a problem on my system. My test data file is slowly gathering some cruft. Between the time I made that SX and now, my locale settings have changes once again. So effectively the 1.000,00 notation is no longer valid.

We have bug 370331 to cover this. Your patch is fine. Sorry for the noise.
Comment 12 John Ralls 2018-06-29 23:15:18 UTC
GnuCash bug tracking has moved to a new Bugzilla host. This bug has been copied to https://bugs.gnucash.org/show_bug.cgi?id=698899. Please update any external references or bookmarks.