Why is my code different than examples?

[jaykellogg]

Is the name of your SubFormControl on the "frmBid" Form the same as the SubForm it is displaying? In other words, are they both named "frmBidSubSetup"?
FYI: I tend to use the Dot "." rather than the Bang "!" as it seems to have less issues when running.
You did not state which line was failing.

mainform "frmBid" has tabs named "tabcontrol". Tab0 is named "Setup". I have a form named "frmBidSubSetup" on the tab "Setup". On the form "frmBidSetup" I have the combobox "PrevailingWages".

The line where I got the error message was the first line of the if/then statement when I try to determine what the combobox PrevailingWages equals.

 

[RuralGuy]

The syntax when using the FOrms collection is:
FORMS.YourFormName.YourSubFormControlName.FORM.YourControlNameOnTheSubForm
The SubFormControl is not necessarily named the same as the SubForm is displays. You know you are looking at the SubFormControl when the Data tab displays the LinkChild/MasterFields properties. The name of the SubFormControl is on the Other tab.

 

[RuralGuy]

Just for the reference, the tab control does not affect the syntax. It is as if it is not even there.

 

[jaykellogg]

The syntax when using the FOrms collection is:
FORMS.YourFormName.YourSubFormControlName.FORM.YourControlNameOnTheSubForm
The SubFormControl is not necessarily named the same as the SubForm is displays. You know you are looking at the SubFormControl when the Data tab displays the LinkChild/MasterFields properties. The name of the SubFormControl is on the Other tab.

Got it to work! I used "Forms.frmBid.frmBidSubSetup.Form.PrevailingWages"

By the way, when you asked for clarification on the control names, I noticed that the subform was named frmBidSetup not frmBidSubSetup. I renamed the form itself but the design screen on frmBid showed the older, incorrect name. I corrected the subform name on the design screen for frmBid.

 

[RuralGuy]

As Galaxiom stated in Post #6, the syntax you were using was referencing the Class Module of the SubForm directly so it was bypassing the SubFormControl completely.

 

[RuralGuy]

Excellent! Are you now good to go? I noticed you are now using the Dot.

 

[jaykellogg]

Excellent! Are you now good to go? I noticed you are now using the Dot.

yep, good to go and using the Dot! I'm going to go through and make all of the syntax changes. If I have any other issues while doing that, I'll post them here.

If I have other issues not related to this syntax changing, should I post them here or create a new thread?

 

[RuralGuy]

I would start a new thread. You can reference this thread if you think it would be helpful. You can also use the Thread Tools at the top of the Thread to mark this thread as Solved.

 

[Galaxiom]

As Galaxiom stated in Post #6, the syntax you were using was referencing the Class Module of the SubForm directly so it was bypassing the SubFormControl completely.

Yes. A hidden instance of the subform would have loaded due to the way it was referenced with Form_.

The instance of the subform in the subformcontrol on the main for is quite separate and can only be referenced via the main form.

 

[Galaxiom]

FYI: I tend to use the Dot "." rather than the Bang "!" as it seems to have less issues when running.

It helps to know what the bang means. Basically it represents the default collection. A form's default collection is Controls.

Forms.formname!controlname

is generally the same as

Forms.formname.Controls.controlname

Where a control by the name is not found the next default is:
Recordset.Fields

so

Forms.formname!controlname

can mean

Forms.formname.Recordset.fieldname

The dot can be substituted in many places in Access objects.

However the bang cannot be substituted for a dot where a Property is being referred to. For example the dot before Visible in:

Forms.formname.Visible

Similarly Form is a Property of a subformcontrol so it needs to be included to get to the form if you use only dots. However .Form can be skipped if the bang is used because the bang will drill to the defaults going via Form to the controls collection of the form's SourceObject.

Forms.formname.subformcontrol!controlname

The dot cannot be substituted in a recordset because it is not an Access object.

rs!fieldname

cannot be substituted with

rs.fieldname

 

[RuralGuy]

Thanks for the Bang Dot explanation. I've bookmarked this thread for use later.