ACC: How to Refer to a Control on a Subform or Subreport

Last reviewed: May 21, 1997
Article ID: Q113352
The information in this article applies to:
  • Microsoft Access versions 1.0, 1.1, 2.0, 7.0, 97

SUMMARY

Moderate: Requires basic macro, coding, and interoperability skills.

This article describes how to refer to controls on subforms or subreports, and describes some common problems you may encounter when you refer to controls on subforms or subreports.

MORE INFORMATION

NOTE: In Microsoft Access 7.0 and 97, the "Form" or "Report" identifier is optional when referring to control properties. It is necessary, however, when referring to subform or subreport properties.

To refer to a control on a subform, use the following syntax:

   Forms![main form name]![subform control name].Form![control name]

To refer to a control on a subreport, use the following syntax:

   Reports![main report name]![subreport control name].Report![control
   name]

NOTE: Only subforms are discussed in the rest of this article, but all the information applies to both subforms and subreports.

It is important to note that you cannot refer to controls on a subform with the following syntax:

   Forms![subform name]![control name]

This is because a subform on a main form is not a form, but is a control just like a text box or a list box. You must refer to a subform as a control rather than a form, and specify the Form identifier following the subform control name reference to gain access to the controls on a subform.

It is also important to note that when you are referring to controls on a subform, you must specify the value contained in the ControlName property of the subform control. The ControlName property should not be confused with the SourceObject property for a subform control. The SourceObject property is used to indicate which subform to use in the subform control. The ControlName property is used to specify the name by which the subform control is referenced. ControlName is typically set the same as the SourceObject, but it does not have to be.

For example, consider an Order Details subform on an Orders form with the following properties:

   ControlName: Order Details
   SourceObject: Order Details

You can refer to a Unit Price control on the Order Details subform with the following reference:

   Forms![Orders]![Order Details].Form![Unit Price]

If, however, the subform control has the following properties

   ControlName: Details
   SourceObject: Order Details

you must refer to the Unit Price control on the Order Details subform with this reference:

   Forms![Orders]![Details].Form![Unit Price]

Examples of Referencing Controls on a Subform

You could use the following SetValue macro action to increase the Unit Price value on the Orders Subform by 10 percent:

   SetValue
      Item: Forms![Orders]![Order Details].Form![Unit Price]
      Expression: Forms![Orders]![Order Details].Form![Unit Price]* 1.1

If the macro is attached to a button on the Orders form, you can use this expression for the SetValue Expression argument:

   [Order Details].Form![Unit Price]*1.1

If you are referring to a control on a subform from another control on the same subform, you do not have to enter the Form property identifier. For example, to refer to the Unit Price value on the Order Details subform in a macro attached to a button on the Order Details subform, you can enter:

   [Unit Price]

The following expression can be entered as the ControlSource property for the Subtotal control on the Orders main form to display a value calculated in the hidden Order Subtotal control on the Order Details subform:

   =[Orders Subform].Form![Order Subtotal]

To refer to the value of a control on the parent (main) form from a control on a subform, use the Parent property. For example, the following expression entered in a control on a subform refers to the Customer ID field on the parent form.

   =Parent![Customer ID]

To refer to a control on a nested subform (a subform on a subform), you can use the following syntax:

   Forms![main form name]![subform control name].Form![nested subform
   control name].Form![control name]

Common Problems Encountered When Referencing Subform Controls

  • The following error message occurs:

          Invalid reference to form '<subform name>'
    

    This means that you tried to reference a control on a subform with the following syntax:

          Forms![subform name]![control name]
    

    The problem is that the subform is not really a form, but a control that appears on a main form. Refer to the subform as a control rather than as a form with the following syntax:

          Forms![main form name]![subform control name].Form![control name]
    

- "#Name?" appears in a control with an expression referring to a
   subform control.

   This can occur when the ControlName property for the subform control is
   not what you expect. Open the main form in Design view, select the
   subform control, then choose the Property window from the View menu.
   Compare the ControlName property value to the SourceObject property
   value.

   The SourceObject property is used to indicate which subform to use
   in the subform control. The ControlName property is used to specify
   the name by which the subform control is referenced. The ControlName
   is typically set the same as the SourceObject, but it does not have
   to be.

  • The following error message occurs:

          Invalid reference to field '<subform name>'
    

    This error message is caused by the same the problem as the problem in the last example.

    REFERENCES

    For more information about controls, type "controls" in the Office Assistant, click Search, and then click to view "Controls: What they are and how they work."


  • Keywords : kbusage SynRef
    Version : 1.0 1.1 2.0 7.0 97
    Platform : WINDOWS
    Hardware : X86
    Issue type : kbhowto


    THE INFORMATION PROVIDED IN THE MICROSOFT KNOWLEDGE BASE IS PROVIDED "AS IS" WITHOUT WARRANTY OF ANY KIND. MICROSOFT DISCLAIMS ALL WARRANTIES, EITHER EXPRESS OR IMPLIED, INCLUDING THE WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE. IN NO EVENT SHALL MICROSOFT CORPORATION OR ITS SUPPLIERS BE LIABLE FOR ANY DAMAGES WHATSOEVER INCLUDING DIRECT, INDIRECT, INCIDENTAL, CONSEQUENTIAL, LOSS OF BUSINESS PROFITS OR SPECIAL DAMAGES, EVEN IF MICROSOFT CORPORATION OR ITS SUPPLIERS HAVE BEEN ADVISED OF THE POSSIBILITY OF SUCH DAMAGES. SOME STATES DO NOT ALLOW THE EXCLUSION OR LIMITATION OF LIABILITY FOR CONSEQUENTIAL OR INCIDENTAL DAMAGES SO THE FOREGOING LIMITATION MAY NOT APPLY.

    Last reviewed: May 21, 1997
    © 1998 Microsoft Corporation. All rights reserved. Terms of Use.