Hi Kevin,

I dont doubt that you are seeing a difference between the versions,
many things have changed from IBO3 to IBO4. What I am saying is that
the code you were using was not guaranteed to work properly even in
IBO3 (the fact that it does/did may make it convenient, but not
recommended).

Many things may cause a datachange event to occur (not just the
obvious things like scrolling and editing). Where practical a field
name may be provided but this is really just for information - code
can be built to optimise those situations but should not rely on that
parameter to always be available.

Where the field information is not readily available, or multiple
fields are involved, or the whole record is involved, or
BeginUpdate/EndUpdate has been used, then the event may occur with no
Field parameter assigned.

In particular events resulting from lookups can impact multiple fields
(multiple entries in the keylinks property). My guess is that IBO4
may have improved its handling to support that situation, resulting in
a change to the way datachange events are fired.

The example code that I posted reflects a relatively common
requirement for datachange event code...

* Is the dataset in the state necessary for the action?

* If the Field parameter is given then that can be used to avoid
unnecessary processing

* If the Field parameter is not assigned you have to assume a
(possibly) record wide change.


--
Geoff Worboys - TeamIBO
Telesis Computing