HELP - Using GoToControl in subforms

[Elaine]

Hi

I have created a form which contains a subform.

To cut a long story short, I have created a macro that moves the focus to
the subform (GoToControl) and sets a value (SetValue) in the field on the
subform that recieves the focus.

The basic steps of the macro are:

GotoControl [subform]
GoToRecord - First
SetValue

This macro works perfectly when I run it from the Tools-Macro-Run Macro
menu. ie. The value I want setting, is set on the first record in the
subform.

But when I trigger the macro by entering a value in the main form
(AfterUpdate), the GoToRecord - First command moves the focus to the first
record in my main form.

Can anyone explain why the macro works perfectly from the tools menu but not
when I trigger it by the After Update event?

I have run the macro through in single steps and tried everything else I can
think of but I think I am defeated by this one (Which sounds so simple).

Can anyone help?

Thanx

[Wayne Morgan]

Setting the focus to a control on a subform is a two step process.

1) Set the focus to the subform control on the main form
2) Set the focus to the control on the subform

You should be able to set the value without setting the focus to the
control. The syntax to refer to a control on the subform is

Forms!NameOfMai nForm!NameOfSub formControl.For m!NameOfControl OnSubform

However, this will place the value in the current record on the subform, not
the first record.

I tried playing with a macro to move the focus to a control on the subform,
but didn't get it right. It is doable in VBA using the method mentioned
above. You can also skip going to the control and just tell the subform to
move to the first record and assign a value to the control.

Example:
Me.NameOfSubfor mControl.Form.R ecordset.MoveFi rst
Me.NameOfSubfor mControl.Form.N ameOfControlOnS ubform = <your value>

--
Wayne Morgan
MS Access MVP
"Elaine" <el**********@v irgin.net> wrote in message
news:qc******** *********@newsf e7-gui.ntli.net...

Hi

I have created a form which contains a subform.

To cut a long story short, I have created a macro that moves the focus to
the subform (GoToControl) and sets a value (SetValue) in the field on the
subform that recieves the focus.

The basic steps of the macro are:

GotoControl [subform]
GoToRecord - First
SetValue

This macro works perfectly when I run it from the Tools-Macro-Run Macro
menu. ie. The value I want setting, is set on the first record in the
subform.

But when I trigger the macro by entering a value in the main form
(AfterUpdate), the GoToRecord - First command moves the focus to the first
record in my main form.

Can anyone explain why the macro works perfectly from the tools menu but
not when I trigger it by the After Update event?

I have run the macro through in single steps and tried everything else I
can think of but I think I am defeated by this one (Which sounds so
simple).

Can anyone help?

Thanx

[David W. Fenton]

"Wayne Morgan" <co************ *************** @hotmail.com> wrote in
news:N_******** ***********@new ssvr11.news.pro digy.com:

Example:
Me.NameOfSubfor mControl.Form.R ecordset.MoveFi rst
Me.NameOfSubfor mControl.Form.N ameOfControlOnS ubform = <your value>

I'm confused by this. Is it not possible for navigation in the
Recordset to cause the same kinds of problems that we refer to as
the Bookmark bug, which involved the RecordsetClone, which previous
to A2K was the only recordset that was usable for navigation? That
is, shouldn't you check for Me!NameOfSubfor mControl.Form.D irty and
set it to False before moving the recordset pointer?

--
David W. Fenton http://www.bway.net/~dfenton
dfenton at bway dot net http://www.bway.net/~dfassoc

[Wayne Morgan]

David,

Checking for a dirty record first and saving it if it is (i.e. setting Dirty
to False) is probably a good idea and definitely won't hurt anything. I
haven't personally run across the bug, although I've heard about it.

--
Wayne Morgan
MS Access MVP
"David W. Fenton" <dX********@bwa y.net.invalid> wrote in message
news:Xn******** *************** ***********@216 .196.97.142...

"Wayne Morgan" <co************ *************** @hotmail.com> wrote in
news:N_******** ***********@new ssvr11.news.pro digy.com:

Example:
Me.NameOfSubfor mControl.Form.R ecordset.MoveFi rst
Me.NameOfSubfor mControl.Form.N ameOfControlOnS ubform = <your value>

I'm confused by this. Is it not possible for navigation in the
Recordset to cause the same kinds of problems that we refer to as
the Bookmark bug, which involved the RecordsetClone, which previous
to A2K was the only recordset that was usable for navigation? That
is, shouldn't you check for Me!NameOfSubfor mControl.Form.D irty and
set it to False before moving the recordset pointer?

--
David W. Fenton http://www.bway.net/~dfenton
dfenton at bway dot net http://www.bway.net/~dfassoc

[David W. Fenton]

"Wayne Morgan" <co************ *************** @hotmail.com> wrote in
news:tV******** ***********@new ssvr11.news.pro digy.com:

Checking for a dirty record first and saving it if it is (i.e.
setting Dirty to False) is probably a good idea and definitely
won't hurt anything. I haven't personally run across the bug,
although I've heard about it.

I think that anytime you know that an action that you're taking is
going to depart a record, it's a good idea to explicitly save the
record. This forces all error checking routines to run, whereas it's
clear that in some circumstances (e.g., the bookmark navigation
situation, the form close bug), that just doesn't happen.

--
David W. Fenton http://www.bway.net/~dfenton
dfenton at bway dot net http://www.bway.net/~dfassoc