On Wednesday 08 March 2006 8:49 pm, Derek Atkins wrote: > David Hampton <[EMAIL PROTECTED]> 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/
pgpY2iUkU8cSd.pgp
Description: PGP signature
_______________________________________________ gnucash-devel mailing list [email protected] https://lists.gnucash.org/mailman/listinfo/gnucash-devel
