[Gnucash-changes] r13352 - gnucash/trunk - Fix "default limit" QOF eventing stuff; thanks Andi.

[Josh Sled]

On Sat, 2006-02-25 at 20:53 +0000, Neil Williams wrote:
> > --- gnucash/trunk/lib/libqof/qof/qofevent.h	2006-02-21 21:46:07 UTC (rev
> > 13351) +++ gnucash/trunk/lib/libqof/qof/qofevent.h	2006-02-21 23:10:33 UTC
> > (rev 13352) @@ -50,11 +50,12 @@
> >  #define QOF_EVENT_REMOVE   (1 << 4)
> > +#define QOF_EVENT__LAST    QOF_EVENT_REMOVE
> >  #define QOF_EVENT_ALL      (0xff)
> 
> (do we need QOF_EVENT_ALL ?)

Maybe not going forward, but it makes sense for the "old-style" events.

> >  /** Allow scope for more defaults in future. Additional
> >  event identifiers must be larger than this. */
> > -#define QOF_DEFAULT_LIMIT  10
> > +#define QOF_DEFAULT_EVENT_LIMIT  QOF_EVENT__LAST
> 
> Josh - why was this a bug? What was wrong with a gap?

The gap was in the wrong direction. :)  The max value (1<<4) is 16, and
10 was less than that.  As event values past the DEFAULT_LIMIT mean "use
the new-style event dispatching", certain events (such as the removals
Andreas was developing against) weren't being delivered.


The change from "10" to QOF_EVENT__LAST (and addition of #define
QOF_EVENT__LAST QOF_EVENT_REMOVE was just to seperate them ... so the
"last event" definition is near (immediately next to) the last event
itself, and the "event limit" definition has it's own comment and
identity.  Just a bit of code-shui.


> Supplementary events will now have to be based on QOF_DEFAULT_LIMIT + n rather 
> than just something bigger than 10?

They should always be specified as based off some constant identifier,
rather than a particular value.  I'm not sure what you mean.


> I thought nobody wanted to iterate over event identifiers?

I have no idea how that relates to this...?

-- 
...jsled
http://asynchronous.org/ - `a=jsled; b=asynchronous.org; echo ${a}@${b}`