To prevent corruption I'm working with an unbound field in my form. The
unbound field's afterupdate event puts the value in the underlying memofield
and saves it. The form's beforeInsert doesn't fire when I start on a blank
record and when the unboud field is the first field that is entered.

In the form's beforeInsert event I have code that enters some values in
different fields.

How can I fix this so when the user starts with the unbound field, that the
form's beforeInsert gets fired and the values get entered?

Thanks,

Lars

Hi Lars

You could check to see if action is required and call BeforeInsert
"manually":

If Me.NewRecord and IsNull(Me.[some field that gets a value]) Then
Call Form_BeforeInsert(0)
End If

The next question is where to out this code?

If you can wait until txtUnboundMemo_AfterUpdate, then insert it there.

If you must have the fields populated before the user types into the field,
use txtUnboundMemo_GotFocus.

If you need to exactly mimic the BeforeInsert behaviour (execute on first
keypress) then use txtUnboundMemo_KeyPress.

--
Good Luck :-)

Graham Mandeno [Access MVP]
Auckland, New Zealand


"Lars Brownies" <(E-Mail Removed)> wrote in message
news:gt7o67$12ng$(E-Mail Removed)...
> To prevent corruption I'm working with an unbound field in my form. The
> unbound field's afterupdate event puts the value in the underlying
> memofield and saves it. The form's beforeInsert doesn't fire when I start
> on a blank record and when the unboud field is the first field that is
> entered.
>
> In the form's beforeInsert event I have code that enters some values in
> different fields.
>
> How can I fix this so when the user starts with the unbound field, that
> the form's beforeInsert gets fired and the values get entered?
>
> Thanks,
>
> Lars
>

Thanks Graham,

>> IsNull(Me.[some field that gets a value])

I can use the autonumber field for that.

> If you need to exactly mimic the BeforeInsert behaviour (execute on first
> keypress) then use txtUnboundMemo_KeyPress.

Good idea!


"Graham Mandeno" <(E-Mail Removed)> schreef in bericht
news:(E-Mail Removed)...
> Hi Lars
>
> You could check to see if action is required and call BeforeInsert
> "manually":
>
> If Me.NewRecord and IsNull(Me.[some field that gets a value]) Then
> Call Form_BeforeInsert(0)
> End If
>
> The next question is where to out this code?
>
> If you can wait until txtUnboundMemo_AfterUpdate, then insert it there.
>
> If you must have the fields populated before the user types into the
> field, use txtUnboundMemo_GotFocus.
>
> If you need to exactly mimic the BeforeInsert behaviour (execute on first
> keypress) then use txtUnboundMemo_KeyPress.
>
> --
> Good Luck :-)
>
> Graham Mandeno [Access MVP]
> Auckland, New Zealand
>
>
> "Lars Brownies" <(E-Mail Removed)> wrote in message
> news:gt7o67$12ng$(E-Mail Removed)...
>> To prevent corruption I'm working with an unbound field in my form. The
>> unbound field's afterupdate event puts the value in the underlying
>> memofield and saves it. The form's beforeInsert doesn't fire when I start
>> on a blank record and when the unboud field is the first field that is
>> entered.
>>
>> In the form's beforeInsert event I have code that enters some values in
>> different fields.
>>
>> How can I fix this so when the user starts with the unbound field, that
>> the form's beforeInsert gets fired and the values get entered?
>>
>> Thanks,
>>
>> Lars
>>
>
>

On Tue, 28 Apr 2009 22:16:07 +0200, Lars Brownies wrote:

> To prevent corruption I'm working with an unbound field in my form. The
> unbound field's afterupdate event puts the value in the underlying
> memofield and saves it. The form's beforeInsert doesn't fire when I
> start on a blank record and when the unboud field is the first field
> that is entered.
>
> In the form's beforeInsert event I have code that enters some values in
> different fields.
>
> How can I fix this so when the user starts with the unbound field, that
> the form's beforeInsert gets fired and the values get entered?

BeforeInsert is not guaranteed to fire. That's the reason I never use it.


--
Rick Brandt, Microsoft Access MVP
Email (as appropriate) to...
RBrandt at Hunter dot com