QOF iteration and callbacks
linux at codehelp.co.uk
Sun Jun 20 11:28:43 EDT 2004
On Sunday 20 June 2004 4:12, Linas Vepstas wrote:
> On Fri, Jun 18, 2004 at 04:49:37PM -0400, Derek Atkins was heard to remark:
> > Neil Williams <linux at codehelp.co.uk> writes:
> > > "one can then ask, at run time, what parameters are associated with a
> > > given type, even if those parameters were not known at compile time."
> > > src/doc/html/group__Class.html
> > Yes, at this point there are no APIs to implement this.
> Whoops. It is straightforward enough to add a 'for-each' function.
> I'll see if I can do that right now.
I've posted the code as it was this morning (see other message) and I can
explain why a GSList of parameter names is sufficient for me and, probably,
would be better than a foreach of the entire list for my needs.
> > > hoping I don't have to copy a whole batch of these sections from the
> > > source tree:
> Ugh. copying ... bad. Foreach, much better. My only concern is that
> I am not convinced that simply asking for all paramters is the right
> thing to do for whatever it is that you are doing.
Iterate through all registered objects
Iterate through those objects listed in the book (need to know the object type
before you can check if it's in the book)
Only if there is something that needs doing should I delve into the actual
parameters. Lumping all the parameter names and data into the mix too early
might lead to some quite large amounts of duplicated data?
The original scenario involved just adding a single invoice - in that case, I
only need to work on certain accounts. Sure, when merging a closed book into
an open book, it'll all come in to play but that may take some time.
> There are very few
> realistic situations where knowing 'all' parameters is the right thing.
When a parameter is empty in the import book, doesn't mean it's empty in the
main book, so when comparing two books, I need to know what is possible,
rather than just what exists in whichever book is in view at the time.
> Most other cases require specialized knowledge of what the object really
> is & does.
That's handled later - I lookup the parameter type from the name and object.
That also gets the get function and I work from there.
This is a very fluid part of the work at the moment, it's precisely what I'm
working on at this moment, so I don't want to set the above in stone. If it's
wrong and I haven't made a reasonable decision to do it differently, now is
the time to change it.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Size: 189 bytes
Url : http://lists.gnucash.org/pipermail/gnucash-devel/attachments/20040620/5264aa13/attachment.bin
More information about the gnucash-devel