I've written a personal finance manager, having become dissatisfied with Gnucash after many years of use. My own system, Newcash, is written in C/GTK3/Sqlite3 (I will be making it available via github when the documentation is ready). In recent months, I've become interested in Haskell (I've written a lot of Lisp and Scheme code over the years) and I re-wrote the Newcash report generator (originally written in Python to process Gnucash's xml file and thus was pretty ugly and needed re-writing) in Haskell. Enthusiastic about the language and pleased with the performance of the report generator, I decided to experiment with re-writing Newcash itself in Haskell, for all the reasons that Haskell is to be preferred to C.
But I've run into a show-stopper. Here's the situation: the Newcash initial window displays the tree of accounts. Not wanting to endure long startup times (a big issue with Gnucash), I initially want to populate the tree model with the root, its children, and its grandchildren. The root gets expanded, so the children are visible, but the grandchildren are present, so the children are expandable. A callback is set up to handle the TreeView's testExpandRow signal, indicating that the user has requested expansion of one of the nodes. I do this initial setup of the accounts window prior to calling mainGUI the first time. This all works fine. The trouble starts if I try to expand one of the root's children by clicking it. The root's grandchildren are already present, but callback attached to the testExpandRow needs to add the grandchildren of the clicked node, so that if it has children, it will appear expandable. The callback receives both an iter and a path to the clicked node. It uses the path in a loop that adds the grandchildren of the clicked node to the TreeStore. This succeeds, but when the callback returns, I get an error message: ** (Newcash:920): CRITICAL **: gtk2hs_store_iter_has_child: assertion 'iter->stamp == store->stamp' failed and the display fails to refresh, with the clicked node expanded. If I click the same node again, it expands correctly (the grandchildren are already present, courtesy of the response to the previous click). I'm guessing that the iter being passed to the callback (which I don't use; as mentioned before, the insertion of the grandchildren is done using the path derived from the path of the clicked node, using treeStoreInsert) has a time-stamp as of the time the first testExpandRow signal was issued. In response to that signal, I add some nodes to the store. I'm guessing that doing so updates the time-stamp on the store and that the two time-stamps are compared upon return from signal processing, and they are no longer equal. The second click does nothing to the store (my callback is smart enough to know that a node has already been processed and doesn't add its grandchildren twice), so the second time the node is clicked, the time-stamp comparison works. ------------------------------------------------------------------------------ CenturyLink Cloud: The Leader in Enterprise Cloud Services. Learn Why More Businesses Are Choosing CenturyLink Cloud For Critical Workloads, Development Environments & Everything In Between. Get a Quote or Start a Free Trial Today. http://pubads.g.doubleclick.net/gampad/clk?id=119420431&iu=/4140/ostg.clktrk _______________________________________________ Gtk2hs-devel mailing list Gtk2hs-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/gtk2hs-devel
