[Gnucash-changes] r13483 - gnucash/trunk - Rework the events generated by the account/group files and consumed by

[Neil Williams]

On Wednesday 08 March 2006 8:49 pm, Derek Atkins wrote:
> David Hampton <hampton-gnucash at rainbolthampton.net> writes:
> >> 2) You've now changed the MODIFY API, and I'm not convinced you've
> >>    changed it globally.  That could be dangerous, in particular if the
> >>    event gets emitted from somewhere that didn't know about the
> >>    change.
> >
> > No, I've added a new modify api using the qof_event_gen function.  The
> > old api using the gnc_engine_gen_event call is still there and is
> > unchanged.

But you're still using the default eventId, QOF_EVENT_MODIFY which is sent to 
old and new handlers. If you want to use the new API, you must define a new 
QofEventId that is larger than QOF_EVENT_BASE.

qof_event_gen still sends events <= QOF_EVENT_BASE to all handlers.

It has replaced the deprecated function by adding extra functionality whilst 
retaining the previous behaviour for the main QOF events.

> > Since the account tree model must use the qof_event system 
> > for the REMOVE notification because of extra data required, it makes
> > sense to use that API for all the events that account tree model
> > watches.
> >
> My concern is that you're generating two different event profiles with
> QOF_EVENT_MODIFY against an Account QofEntity.  I think internally QOF
> has only a single list of callback functions (although I must admit I
> haven't looked closely). 

QofEvent does only have one list, events that use QofEventId <= QOF_EVENT_BASE 
get sent to both new and old handlers. Events where QofEventId > 
QOF_EVENT_BASE only get sent to the new handlers.

> So I think you need to be consistent with 
> how you use QOF_EVENT_MODIFY with an Account QofEntity and be sure
> you're always using the same source and consumer syntax.

If you use QOF_EVENT_MODIFY, it will be sent to the old, deprecated, handlers 
as well as the new. All handlers will therefore have to know how to ignore it 
or handle it.

If you want an event to be handled differently, it's best to create a new 
event and use a handler that uses the new prototype - that's why the enum was 
removed.

As it stands, use of the default QOF events, ADD, REMOVE, MODIFY, CREATE and 
DESTROY neither changes how the handlers receive the event nor how they 
process the event. The handlers can and should expect that the entity 
involved is to be processed in the same way in all handlers.

One event = one definition = one syntax in all handlers.

-- 

Neil Williams
=============
http://www.data-freedom.org/
http://www.nosoftwarepatents.com/
http://www.linux.codehelp.co.uk/

-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
Url : http://lists.gnucash.org/pipermail/gnucash-devel/attachments/20060308/c04dd59f/attachment.bin