How to reference a control on Tab Control from the Main Form (1 Viewer)

[The_Doc_Man]

Inspecting the Form object will help you clear any doubts about Parent references. Several members of the Form class inherit Parent. In the example I provided, I'm using Parent to reference the same textbox from the BorderStyle property, an exercise to demonstrate that even a property can be used to reach the control. Information that is easy to understand through inspection.

Since inspection is never mentioned in threads about referencing controls, developers may get the wrong idea that there's only one way to do things, especially when they're presented with the link in post #6, when the information has always been in plain sight, not even hidden, because developers see it all the time while trying to debug the reference (if their locals window is visible). The syntax I'm using is THE exercise we should all be presented with when trying to reference something. The syntax is long, but it's consistent and you can use shortcuts if you want, like I mentioned. However, posts #2, #3, #5, #6, #7, #10 and #14 are using shortcuts, especially the link in post #6, which combines default members, bang and dot notation. How could new developers not get confused with this amount of variation?

I certainly don't want to suggest (for even a moment) that the long-sequence references to an object are technically wrong. However, given that the general category of Access is that it is a Rapid Application Development tool, the more you have to type, the less rapid it gets. For newbies and folks who have a congenital aversion to typing, shortcuts are essential tools in the toolbox. But let me ask this: When you use long-sequence references, do you start from Workspaces(0).Databases(0) - or maybe do you start from CurrentDB? OR, since CurrentDB is the default, do you just start with Me.something sometimes? I.e. is there a limit to how explicit your references will be?

 

[561414]

I certainly don't want to suggest (for even a moment) that the long-sequence references to an object are technically wrong. However, given that the general category of Access is that it is a Rapid Application Development tool, the more you have to type, the less rapid it gets. For newbies and folks who have a congenital aversion to typing, shortcuts are essential tools in the toolbox. But let me ask this: When you use long-sequence references, do you start from Workspaces(0).Databases(0) - or maybe do you start from CurrentDB? OR, since CurrentDB is the default, do you just start with Me.something sometimes? I.e. is there a limit to how explicit your references will be?

Well, consider the amount of wasted time for a new developer. Googling answers, trying and failing with possible syntax combinations, all looking different and for very different form setups and not even a single post read by this new developer even mentioned inspecting the Form. I've been there, I'm no stranger to the hours and hours wasted. You have to resort to a forum and wait for the reply to your particular scenario, if you're lucky. Typing a few extra words is what, a few seconds more? We're programming, each line is been crafted carefully, it's not like we're writing code like we're writing an essay. Form inspection is the source of truth, go check there first, always.

By the way, this is not a RTFM thing, it's reverse engineering. A lot of undocumented stuff can be found out from inspecting objects. And in this regard, when I'm debugging a form, I really can't remember any time I have seen the Workspaces or Databases objects, I get Me in forms and Application in modules, it depends, of course. So I start from either of them. The Access documentation is very vague, one must resort to these things, so, in conclusion, shortcuts are actually advanced, not beginner friendly.

By the way, anyone knows how to late bind with withEvents?

 

[MajP]

@561414. My point is subtle but I think you are missing it.

This reference

me.txtSomeTextBox.value

is not a shortcut to the below notation.

Me.Controls.Item("TabCtl0").Pages.Item("page2").Controls.Item("child_form").Controls.Item("txtSomeTextbox").Value

These are two parallel paths not a shortcut of one path. MS deliberately adds the controls on the tab to both the controls collection of the page as well as directly to a property of a form.

A shortcut of this notation

Me.Controls.Item("TabCtl0").Pages.Item("page2").Controls.Item("child_form").Controls.Item("txtSomeTextbox").Value

is below with all the default properties removed. This still follows the same reference path as above but the notation has been shortened. Both references go through the form's control collection, through the pages collection, through the pages' controls collection

Controls("TabCtl0").Pages("page2").Controls("child_form")("txtSomeTextbox")

In the first case I think calling one a "shortcut" of the other is confusing, because Access does have a lot of shortcut notation with default properties and methods. This alternate path is a different object model.

A complete discussion on default properties and Bang vs DOT may find interesting.

Lets Kill the Me. vs Me! sticky or lets rewrite it

This discussion moved to clean thread https://www.access-programmers.co.uk/forums/threads/bang-vs-dot-me-and-default-properties.327749/

www.access-programmers.co.uk

 

[The_Doc_Man]

The Access documentation is very vague,

On this point, we can agree. MS Online documentation is so inconsistent that to say it bites is an insult to vampires everywhere from being placed in the same class.

My problem is that, sure, I can use (for example) the locals window to expand something and see what is in it - and I have done so more than once. But most of the objects that you want (and most of the ways you will want them) are available as the default property (or one might say "preferred" property) for the object. What a new developer will learn from the Locals Window inspection is that there is a lot of crap in there that would take a while to recursively evaluate. JUST what a new developer wants to hear... recursive enumeration.

For an advanced developer it makes perfect sense to have that tool in the toolbox as a way to find where something is located. (HINT: Don't try this with an Excel App object working with an embedded Chart or SmartArt object unless you have a barf bag handy.) For an experienced software developer who is new to the C.O.M. environment, however, more traditional ways of looking up stuff might be a tiny bit easier. Just one man's opinion, and we all know what is said about opinions.

 

[561414]

@MajP Dude, I presented a lot of different ways to reference a control and then I invited the reader to find other references because the point was that there are a lot of ways. Not only that, I also provided proof, samples and, most importantly, the resources and methodology to find even more things and keep exploring. It is the very definition of the scientific method.

I said shortcuts are advanced and you linked me exactly to the demonstration of that. In that post, you talk about classes, default members of a class, the use of Me and a few other things that even posters with large post counts are confused with. You are not providing any evidence that can be tested, you didn't even mention the object browser, which is the best place to find who's a default member of who. By the way, where did I say me.txtSomeTextBox.value is the shortcut of Me.Controls.Item("TabCtl0").Pages.Item("page2").Controls.Item("child_form").Controls.Item("txtSomeTextbox").Value?

@The_Doc_Man I haven't checked what microsoft chose to show in the locals window for all the objects of all its applications, but the Form object is quite reliable, as demonstrated.

 

[MsAccessNL]

I haven’t read all the replies, but i think there is a simple way. Make sure that your subform/childform has an [event procedure] this can be without any code, then you can reference any control directly by just using. Form_SubformName.controlname. That’s all. You also will get intellisense…