Subject Events trap (API programming, bug or per design) ?
Author Mascia, Olivier
-----BEGIN PGP SIGNED MESSAGE-----

I have found that when first calling isc_que_events(), the AST trap
is called a first time nearly immediately. And all the counts are set
to 1.

A rather obscure note at the end of chapter 11 of API Guide,
paragraph "Determining which events occurred with
isc_event_counts()", says :

>>>>>>>>
Note : When first setting up an AST to trap events with
isc_que_events(), InterBase initializes all count values in the
status vector to 1, rather than 0. To clear the values, call
isc_event_counts() to reset the values.
<<<<<<<<

It looks like it, indeed, triggers the AST trap a first time with a
temporary result buffer where all counts are 1. I find this 'bizarre'
and it smells like bug. I work-around it in my code by setting the
counts in events buffer (not result buffer) to 1 before my first call
to isc_que_events(). So when this first unwanted trap occurs, I do
not 'see' false events triggers.

Would this be by design ?
For what reason ? What was the reason for this initial AST call and
why with ones and not zeroes ?

I will try to understand the original intention from the source code,
but if someone has the answer right of-hat...

Olivier.


-----BEGIN PGP SIGNATURE-----
Version: PGP Personal Privacy 6.5.8

iQEVAwUBOg7jG6IodNUVZIMJAQHdGQgAja0p9Km7Yw+B4crk5WRpWYFrLz/dxuCA
NCq5fMYnyZxjFBTziq05zC1euk7CcNOVhFK6ESEvzN+Bx5trHV7xX1lpm4iG3h32
HoQmc0YFabWDuCI/RJKijKdNWAoD4klReOwnFn7yTD/mEC4tVvk77BF4W+t4iB02
cqI3cuZsefR7RpsYjT6IEEK8ecqR4Pj8jQPpj45bWt0mnx0t/mnB4o9m13MPhUIV
uAtBZdkfq2FloZ4MZfbEg6qEYR8JA1WBMqN1+krITHB6g+M3y3lUlcoKeYr7UG+A
SeqeNlELb3DYTaJ8Ibcos9Tcc0uz8s70b6FzPYnUOWGtbI9kXnl2DQ==
=m7uh
-----END PGP SIGNATURE-----