Forms Events & Invalid use of Null

[Mike]

Greetings,

It would seem that this topic has been discussed at some length, but I
was unable to discern whether there was a clear cut solution to resolve
and/or otherwise workaround the issue.

Briefly, I have some code which queries the database from a subform,
and enables or disables a contol in the parent form, depending upon the
results I receive.

This seems to be working for post-insert and post-update events.
However, when I connect the code with current and post-delete events,
then I begin receiving the infamous "Invalid use of Null".

Without going into a lot of detail about the code, I am 99.9% confident
the code is not to blame. As I stated, it works without error for
certain events, but just not others. So that begs the question, is
there a more appropriate event I could be handling? I am hoping ther
answer is yes.

The bottom line for me is to detect any change in the state of the
subform's recordset (insert, update, and delete) and report that back
to the parent form in the form of enabled or disabled control Any
insight in this area would be greatly appreciated.

Regards,
Michael

[Mike]

Well, I was able to get around it (more or less) by handling the 94
error in my On Error block. I didn't know of any other way to hide this
detail from the user.

Now I am trying to understand the event timing. I have event handlers
for On Current, After Insert, After Update, and After Del Confirm. All
but After Insert are being handled properly.

After Insert does not appear to be firing and I don't know why. This is
important because after a record (first record) has been inserted I
would like for the user interface to disable the parent control.

Any ideas how to workaround this issue?

Mike wrote:

Greetings,

It would seem that this topic has been discussed at some length, but I
was unable to discern whether there was a clear cut solution to resolve
and/or otherwise workaround the issue.

Briefly, I have some code which queries the database from a subform,
and enables or disables a contol in the parent form, depending upon the
results I receive.

This seems to be working for post-insert and post-update events.
However, when I connect the code with current and post-delete events,
then I begin receiving the infamous "Invalid use of Null".

Without going into a lot of detail about the code, I am 99.9% confident
the code is not to blame. As I stated, it works without error for
certain events, but just not others. So that begs the question, is
there a more appropriate event I could be handling? I am hoping ther
answer is yes.

The bottom line for me is to detect any change in the state of the
subform's recordset (insert, update, and delete) and report that back
to the parent form in the form of enabled or disabled control Any
insight in this area would be greatly appreciated.

Regards,
Michael

[deluxeinformation]

Mike wrote:

Well, I was able to get around it (more or less) by handling the 94
error in my On Error block. I didn't know of any other way to hide this
detail from the user.

Now I am trying to understand the event timing. I have event handlers
for On Current, After Insert, After Update, and After Del Confirm. All
but After Insert are being handled properly.

After Insert does not appear to be firing and I don't know why. This is
important because after a record (first record) has been inserted I
would like for the user interface to disable the parent control.

Any ideas how to workaround this issue?

Mike wrote:

Greetings,

It would seem that this topic has been discussed at some length, but I
was unable to discern whether there was a clear cut solution to resolve
and/or otherwise workaround the issue.

Briefly, I have some code which queries the database from a subform,
and enables or disables a contol in the parent form, depending upon the
results I receive.

This seems to be working for post-insert and post-update events.
However, when I connect the code with current and post-delete events,
then I begin receiving the infamous "Invalid use of Null".

Without going into a lot of detail about the code, I am 99.9% confident
the code is not to blame. As I stated, it works without error for
certain events, but just not others. So that begs the question, is
there a more appropriate event I could be handling? I am hoping ther
answer is yes.

The bottom line for me is to detect any change in the state of the
subform's recordset (insert, update, and delete) and report that back
to the parent form in the form of enabled or disabled control Any
insight in this area would be greatly appreciated.

Regards,
Michael

If you're inserting a record via the subform, its AfterInsert event
should fire. It will not cause the parent's AfterInsert event to fire.
Nor will updating an existing record cause the AfterInsert to fire.
Also keep in mind that the subform loads prior to the parent so all of
its relevant form events (load, open, current, etc.) will fire prior to
the parent's events when the parent form is first opened.

Try setting a breakpoint in your AfterInsert code and step through it
to see where the problem lies.

Bruce