> Then how in the heck to I detect the customer number changing? The
> code I posted in the original email came from Jason quite some time
> ago.

Well hopefully Jason will correct me if I have been giving bad advice.
I just compared what I believe to be the equivalent sections of code
between IBO4 and IBO3.6.D (sorry I dont have 3.6.Cf), and I dont
actually see any difference. Quite possibly there is something else
going on which impacts the end result, but I cant see it at the
moment.

> It works perfectly w/ an IB_Edit but not w/ a TIB_LookupCombo. My
> personal opinion is the TIB_LookupCombo is not functioning properly.

Remember that I said it is NOT lookupcombo that does the keylink
updates - it is the lookup dataset itself. If you lookup at
TIB_Dataset.IMP and the procedure TIB_Dataset.SysUpdateKeyLinksData;
you will see where the keylink fields are matched and assigned. The
key code relating to your problem is...

KeyDataset.Fields.BeginUpdate;
try
...
finally
KeyDataset.Fields.EndUpdate( true );

The EndUpdate(true) causes the row to issue a single event (Field=nil)
for the change - instead of issuing individual change events for each
column that was altered.

> I don't want to do the code (set field values, etc) every time the
> event fires (Field.FieldName - nil), I only want to change fields in
> the record when the user changes the customer number. How can I do
> this?

I can think of a few ways of doing this...

1. Attach your code to the lookup dataset, and when the selection is
changed (and the main dataset is in insert/edit) then update the
various fields.

2. Actually test for column changes in the datachange event.

3. Use the OnAfterModify event of the TIB_Column. Assign the event
handler in the AfterPrepare event of the main dataset.

4. Do the assignments in before insert/update triggers at the server.

> There has to be a way to capture when a field value changes. Forever
> it has been in the OnDataChange event, testing Field.FieldName for
> the appropriate field.

> What is the correct way now?

LookupCombo is very different to other controls. Both because it is
not directly linked to the primary dataset anyway AND because it can
impact multiple columns in the primary dataset depending on the
configuration of the lookup dataset. I suggest that option 1 above is
probably an appropriate way of responding to user initiated changes to
the lookup selection - because in that situation you know that the
lookup dataset is present and lined up with the record from which you
want to get your data.

Option 4 above is probably the _safest_ option, since it would ensure
that the values are assigned even with data input from other sources.
You can easily setup checks for value changes in the triggers so that
the assignments are only made if the New.* does not equal the Old.*.

As you mentioned, your original code is probably reasonably safe for
non-key related data, since updating from a normal *control* should
always result in a datachange event with Field parameter provided.

It is only "reasonably" safe because there are other ways of updating
a record other than through a control. For example; if you setup an
import function in which you used Fields.BeginUpdate/EndUpdate(true)
as described above then you would end up with similar difficulties.

hth

--
Geoff Worboys - TeamIBO
Telesis Computing