Microsoft KB Archive/282337

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

Article ID: 282337

Article Last Modified on 11/5/2003

-

APPLIES TO


 * Microsoft Access 2002 Standard Edition

-



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:  Create a new database named ArgTest.mdb . Create a new module from the Database window.  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  On the toolbar, click Save. Name the module ArgCode and close the Visual Basic Editor.  Create a new form in Design view and add a command button with the following properties:     Name:     PropertyS Caption: PropertyS On Click: =MsgBox(&quot;Arguments are &quot; & ArgListS(&quot;P1&quot;,&quot;P2&quot;,&quot;P3&quot;))  Save the form as FormTest. On the View menu, click Form View.</li> Click the PropertyS button.

The arguments appear in the expected order.</li></ol>

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: <ol> In the ArgTest.mdb file created in the first example, create a new form in Design view.</li>  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 </li> Close the Visual Basic Editor and save the form as FormCode .</li> On the View menu, click Form View, and then minimize the form.</li> Open the form FormTest in Design view.</li>  Add a new command button with the following properties: <pre class="fixed_text">    Name:     Procedure Caption: Procedure On Click: [Event Procedure] </li>  On the View menu, click Code and enter the following procedure: Private Sub Procedure_Click

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

End Sub </li> Close the Visual Basic Editor, switch to Form view and click the Procedure button.

The arguments appear in the expected order.</li></ol>

<div class="status_section">

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

<div class="moreinformation_section">

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(&quot;Opening &quot; & 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
<ol> Create a new database named MyTest.mdb .</li> Create a new form in Design view.</li>  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 </li> Close the Visual Basic Editor and save the form as MyFormCode .</li> On the View menu, click Form View, and minimize the form.</li>  Create another new form in Design view and add a command button with the following properties: <pre class="fixed_text">    Name:     PropertyC Caption: PropertyC On Click: =MsgBox(&quot;Arguments are &quot; & Forms![MyFormCode].ArgListC(&quot;P1&quot;,&quot;P2&quot;,&quot;P3&quot;)) </li> <li>Save the form as MyFormTest, and on the View menu, click Form View.</li> <li>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.</li></ol>

<div class="references_section">