ACC2002: Argument Order Is Reversed When an Event Property Is a Function in Another Form's Class Module (282337)


The information in this article applies to:

  • Microsoft Access 2002
This article was previously published under Q282337
Moderate: Requires basic macro, coding, and interoperability skills.

This article applies to a Microsoft Access database (.mdb) and to a Microsoft Access project (.adp).

SYMPTOMS

When you set the event property of a control in one form to be a function that is declared in the class module of another form, the order in which the arguments is processed is reversed.

RESOLUTION

You can work around this behavior in either of two ways:
  • Define the required function in a standard module rather than in a form's class module.
  • Use the control's event procedure to call the function from another form, rather than setting the value of the function as the control's event property.

Method 1: Save the Function in a Standard Module

When functions need to be called from more than one form or other database object, it is often best to save them in standard modules. To use a function in a standard module, follow these steps:
  1. Create a new database named ArgTest.mdb.
  2. Create a new module from the Database window.
  3. In the Code window, enter the following function:
    Function ArgListS(p1 As String, p2 As String, p3 As String) As String

    ArgListS = p1 & p2 & p3
    MsgBox ArgListS

End Function
  4. On the toolbar, click Save. Name the module ArgCode and close the Visual Basic Editor.
  5. Create a new form in Design view and add a command button with the following properties:
         Name:     PropertyS
     Caption:  PropertyS
     On Click: =MsgBox("Arguments are " & ArgListS("P1","P2","P3"))
  6. Save the form as FormTest. On the View menu, click Form View.
  7. Click the PropertyS button.

    The arguments appear in the expected order.

Method 2: Use an Event Procedure to Call a Function from Another Form's Class Module

If you do not want to relocate a form's function to a standard module, you can still call it from a different form, but you should use an event procedure to do so. To do that in this example, follow these steps:
  1. In the ArgTest.mdb file created in the first example, create a new form in Design view.
  2. On the View menu, click Code and enter the following function:
    Function ArgListC(p1 As String, p2 As String, p3 As String) As String

    ArgListC = p1 & p2 & p3
    MsgBox ArgListC

End Function
  3. Close the Visual Basic Editor and save the form as FormCode.
  4. On the View menu, click Form View, and then minimize the form.
  5. Open the form FormTest in Design view.
  6. Add a new command button with the following properties:
         Name:     Procedure
     Caption:  Procedure
     On Click: [Event Procedure]
  7. On the View menu, click Code and enter the following procedure:
    Private Sub Procedure_Click()

   MsgBox ("Arguments are " & Forms![FormCode].ArgListC("P1","P2","P3"))

End Sub
  8. Close the Visual Basic Editor, switch to Form view and click the Procedure button.

    The arguments appear in the expected order.

STATUS

Microsoft has confirmed that this is a problem in the Microsoft products that are listed at the beginning of this article.

MORE INFORMATION

The properties of events such as On Open and On Click can be set as event procedures or macros, or they can be set as the return values of functions. For example, if you set a form's OnOpen property to be =MsgBox("Opening " & Name), opening the form will display a message box identifying the form.

In this case, the function is a built-in Access function and is always available. You can also use functions that you have created yourself, but if you do, you need to take care that the function is used correctly and that its arguments are processed as you intend.

When you create your own functions, they are saved either in a standard module or in a form's class module. Functions saved in standard modules are available to all other objects in the database just by invoking their names, but functions saved in class modules must be referenced through the name of their associated form. For example, a function named FunctionOne() might be used this way if it were saved in a standard module: 
varValue = FunctionOne()
The function would be used this way if it were saved in the class module of a form named FormOne: 
varValue = Forms![FormOne].FunctionOne()


NOTE: It is important that in the second case, FormOne needs to be open when the function is used.

If you need to use a function in response to an event on one form, and the function is defined in the class module of another form, you may find that the arguments are not processed in the order that you expect. The following example shows this behavior.

Steps to Reproduce the Behavior

  1. Create a new database named MyTest.mdb.
  2. Create a new form in Design view.
  3. On the View menu, click Code and enter the following function:
    Function ArgListC(p1 As String, p2 As String, p3 As String) As String

    ArgListC = p1 & p2 & p3
    MsgBox ArgListC

End Function
  4. Close the Visual Basic Editor and save the form as MyFormCode.
  5. On the View menu, click Form View, and minimize the form.
  6. Create another new form in Design view and add a command button with the following properties:
         Name:     PropertyC
     Caption:  PropertyC
     On Click: =MsgBox("Arguments are " & Forms![MyFormCode].ArgListC("P1","P2","P3"))
  7. Save the form as MyFormTest, and on the View menu, click Form View.
  8. Click the PropertyC button.

    Notice that the arguments are displayed in reverse order, as well as that the message from the ArgListC() function is displayed twice.

REFERENCES

For more information about standard modules and class modules, click Microsoft Access Help on the Help menu, type module in the Office Assistant or the Answer Wizard, and then click Search to view the topics returned.
Modification Type:MajorLast Reviewed:11/5/2003
Keywords:kbbug kbpending KB282337
©2003 Microsoft Corporation. All rights reserved.