Setting a form as a variable (1 Viewer)

[grenee]

Good Day All,

I want to create a variable of Form type. Then I want to access the members. This code is my effort, But it is not working. Would appreciate some advise

    Dim PoForm As Form
    
    Set PoForm = Forms![Purchase Orders Payments]
    
    PoForm.Currency

 

[The_Doc_Man]

First, since "Currency" is a data type name, it is not a good choice.

Second, you are using "property" syntax, not "member" syntax. With Currency as a reserved word, it would look to Access like you were searching the form for that name as a property. Which will fail since there is no form property called Currency.

Third, be sure that the form is open before trying this since if the form is not open, the controls are only virtual.

Try

Set PoForm = Forms![Purchase Orders Payments]
PoForm![Currency] = ...
(or)
something = PoForm![Currency]

But it would be a really good thing to name-change any controls that happen to match ANY Access keywords. I'm always unhappy to realize that Access took up all of the really good keywords like Date, Time, Height, Width, etc... but then, having a more specific name like MyHeight or StartDate helps in the long run because of mnemonic value.

 

[grenee]

Thanks Mr_Doc_Man for your assistance and guidance.

I applied your council but I am still getting a little error message so maybe you can assist further:
Here is my new code:

Dim PoForm As Form
    Dim a As String
    
    Set PoForm = Forms![Purchase Orders Payments]
      a = PoForm![PayAmt]
    MsgBox a

This is the error message:

There is an invalid use of the . (dot) or ! Operator or invalid parenthesis

 

[isladogs]

You haven't said where the code is being used

Try a = PoForm.PayAmt

 

[June7]

Why do you want to do this? I have never found the need to declare and set a form object variable.

However, code works for me using ! (bang) or . (dot).

Is the form actually being used as a subform? If so, this code won't work.

 

[The_Doc_Man]

Galaxiom had a really good post about the virtues of dot (.) vs bang (!) and when each was appropriate. Where there is no ambiguity, the dot and bang work equally well for a control, though bang doesn't work for everything.

However, June7, the syntax in question should work. It might not look orthodox, but as long as the named form is open, there is no ambiguity in the path from the forms collection through the named form to a control residing on that form. Were you perhaps thinking of another way to reference the form?

Grenee, your Forms![form name] syntax is not wrong, but you COULD also have used an alternative syntax - Forms("form name") - as a way to specify the form as a named member of the Forms collection. The "SET" syntax will accept a form reference that way, too.

    Dim PoForm As Form
    ...
    Set PoForm = Forms("Purchase Orders Payments")
    MsgBox PoForm![PayAmt]

    ...    (or)

    MsgBox Forms("Purchase Orders Payments")![PayAmt]

    ...

My last example should work without the DIM statement or any extra variable.

As to dot/bang issues, see this thread and the links within it.

https://access-programmers.co.uk/forums/showthread.php?t=299717&highlight=Dot+Bang

 

[June7]

I agree it should work (it did for me, as stated) if the form is open as a FORM and not a SUBFORM.

 

[grenee]

I tried this recommendation:

   a = PoForm.PayAmt

but it throws the same error message:

 

[grenee]

Why do you want to do this? I have never found the need to declare and set a form object variable.

However, code works for me using ! (bang) or . (dot).

Is the form actually being used as a subform? If so, this code won't work.

The form is not being used as a subform.

My ultimate objective is to pass some of the form's text fields as byref arguments to a function where the text fields can be tested for emptiness etc. The function would return a Boolean result.

I know that the test can be done directly on the opened form but I want a generic function that can be used on several forms when the need arises.

So at the moment I making sure that the process for referencing the form as variable works before I go on to the next step. Obviously if it can't work here it can't be passed as a parameter to a function.

 

[June7]

Since I cannot replicate the issue, perhaps you should provide db for analysis. Follow instructions at bottom of my post.

 

[grenee]

Galaxiom had a really good post about the virtues of dot (.) vs bang (!) and when each was appropriate. Where there is no ambiguity, the dot and bang work equally well for a control, though bang doesn't work for everything.

However, June7, the syntax in question should work. It might not look orthodox, but as long as the named form is open, there is no ambiguity in the path from the forms collection through the named form to a control residing on that form. Were you perhaps thinking of another way to reference the form?

Grenee, your Forms![form name] syntax is not wrong, but you COULD also have used an alternative syntax - Forms("form name") - as a way to specify the form as a named member of the Forms collection. The "SET" syntax will accept a form reference that way, too.

    Dim PoForm As Form
    ...
    Set PoForm = Forms("Purchase Orders Payments")
    MsgBox PoForm![PayAmt]

    ...    (or)

    MsgBox Forms("Purchase Orders Payments")![PayAmt]

    ...

My last example should work without the DIM statement or any extra variable.

As to dot/bang issues, see this thread and the links within it.

https://access-programmers.co.uk/forums/showthread.php?t=299717&highlight=Dot+Bang

I tried both ways by there is still a problem.

Here is another observation that might help you to help me.

When I use

me.PayAmt

From the time I enter the . (dot) after me, I get a drop down list that displays all the member which I put on the form along with the access members. However when I enter the . (dot) after PoForm I get only the Access members. Now that throw a red flag for me because after both dots should have the same response since I am referencing the same form.

 

[The_Doc_Man]

Regarding ME vs the form variable, no. They should NOT be the same.

Using "Me." triggers a drop-down list of the elements currently defined in the form being considered, and I will infer that you are dealing with code in the form's Class module - because that drop-down based on "Me." can't occur in a general module. Further, to enter code, you are in design mode.

Using the form object variable, you might have provided a code line before that to define which form object you wanted to use, but at design time that form object variable is not populated. The code hasn't executed yet, so you cannot expect to see the members YOU have added (to the form). You can ONLY expect to see elements that are part of the basic object definition. Therefore, what you describe is exactly what I would have expected to see.

 

[Uncle Gizmo]

My ultimate objective is to pass some of the form's text fields as byref arguments to a function where the text fields can be tested for emptiness etc.

"Some of the Text fields"

What identifies the ones you want to inspect?

What feature?

If not a feature, then how do you mark them?

Something in the tag property?
A coding of the control name?
Possibly you select then by there contents, date, numeric, text. ..

Once you specify how you identify the controls, then it would be quite easy to write a routine that would inspect all of the controls in the forms controls collection, select the particular controls by the method you use to identify them, then test them, change them, report on them, what ever you require...

See. My blog here:-

http://www.niftyaccess.com/loop-through-a-set-of-controls/

Which demos the method I'm suggesting...


Sent from my SM-G925F using Tapatalk

 

[MarkK]

All forms that you create inherit from Access.Form, so you can run code like this...

Private Sub Command7_Click()
    Debug.Print [COLOR="DarkRed"]"The current form is type:"[/COLOR], TypeName(Me)
    Debug.Print [COLOR="darkred"]"Is Me a Form object? "[/COLOR], TypeOf Me Is Form
    Debug.Print [COLOR="darkred"]"Is Me a Form_Form3 object? "[/COLOR], TypeOf Me Is Form_Form3
End Sub

... which prints this to the immediate pane ...

The current form is type:   Form_Form3
Is Me a Form object?        True
Is Me a Form_Form3 object?  True

... showing that the object is a Form and Form_Form3 at the same time.

If you want to see intellisense showing the custom methods and properties of your form, then declare a variable of that type by changing...

    Dim PoForm As Form

... to ...

    Dim PoForm As Form_[COLOR="Purple"]fMyPoForm[/COLOR]

... where the purple part is the name of your form.
hth
Mark

 

[grenee]

"Some of the Text fields"

What identifies the ones you want to inspect?

What feature?

If not a feature, then how do you mark them?

Something in the tag property?
A coding of the control name?
Possibly you select then by there contents, date, numeric, text. ..

Once you specify how you identify the controls, then it would be quite easy to write a routine that would inspect all of the controls in the forms controls collection, select the particular controls by the method you use to identify them, then test them, change them, report on them, what ever you require...

See. My blog here:-

Loop Through a Set of Controls

Which demos the method I'm suggesting...


Sent from my SM-G925F using Tapatalk

I followed the video on this link and it provided me with exactly what I needed; that is to pass a text box to a function. Actually the solution example is in not in the text box video but rather in the check box video. Anyways it is working fine.

Thank to you and all the others who offered me assistance today. I would actually study some of the other solution too to see if there is more to pickup