Forms/controls Example (1 Viewer)

Dreamweaver · Jan 6, 2019

I am currently working on a forms, subform controls example if you are having problems with working with controls or subform please post a request for inclusion if you think a screen shot will help please post one but keep it simple like

I'm trying to access subform 2 textbox from subform 1

I've added an image of what I've done today.

Cronk · Jan 6, 2019

I'm trying to access subform 2 textbox from subform 1

Is that a question? If so, then the code in a subform2 module would be

Code:

me.parent.Subform2.form.Yourtextbox

Dreamweaver · Jan 6, 2019

Cronk said:
Is that a question? If so, then the code in a subform2 module would be

Code:

me.parent.Subform2.form.Yourtextbox

No I'm the one building the example thought that was clear.

I don't like using Me.parent just me lol

Cronk · Jan 6, 2019

Ok. How about

Code:

forms!YourForm.subform2.form.YourTextBox

Uncle Gizmo · Jan 7, 2019

MickJav said:
I don't like using Me.parent just me lol

I just thought I should mention seeing as you are interested in forms and sub-forms, you might be interested in my CallCalled Class Module. There's a limited amount of information about it here:-

http://www.niftyaccess.com/callcalled-class-module/

When I first discovered how some of the pop-up calendars worked, basically you linked the control you wanted the date to be placed in to the Pop-Up form containing the calendar. This link is called an object reference. This means that the two linked objects behave as one, so if you make changes in one object, the changes appear in the other object.

Linking the objects in this way meant that the calendar form could be called from any textbox, combobox (whatever object you wanted to link the calendar to) and the date would be passed back into the link object. In other words it would work on subform after subform with no problem. However it lacked one feature that I particularly wanted.

Let's say you entered somebody's birthdate and you wanted another textbox to display their age. You could pop up the calendar form, it would pass their birthday back in to the text box, but then you would need to operate some other event to cause the age to be calculated.

In other words the linking of the objects was OK for passing information between the two objects but there was no way to trigger the after update event of the object that the Calendar Form was called from. Hence, the calculation of the age was not possible without some other action.

I wrote some code in the Calling form which I called a "Passback" routine the passback routine would be triggered by the Called Form (the calendar form) and update the age textbox. This worked fine until your control happened to be on a subform.

The funny things about subforms is the form doesn't actually exist programatically, it exists as a form in a subform/subreport control. In other words it's very difficult to gain access to it, especially if it's several subforms deep.

That's what my class module does, it allows you to access a deeply buried subform and Trigger code within it. By this method it is possible to simulate the after update event.

Your comment about selecting parent, reminding me because the code iterates up through the parents until it finds the main form, the top form, the form that isn't a subform.

Dreamweaver · Jan 7, 2019

I do remember reading in one of the books I learnt from That using me.parent was a bad idear and it stuck Still can't remember why though it's like referencing controls on a form I always use Me![ControlName] but if I want to access the data supplying the form I would Use Me.FieldName that's the way I learnt back in 1998 onwards Access V2 anybody remember that beast.

I do intend added forms working together as part of the example so may include the age but was thinking of collecting input for SLN or SYD Depreciation Another thing people don't Understand and to be honest it keeps me up at night sometimes lol

Uncle Gizmo · Jan 7, 2019

MickJav said:
I do remember reading in one of the books I learnt from That using me.parent was a bad idea

I haven't heard that before?

However there is one problem with me parent, if you are assigning the parent to an object variable, and the parent turns out to be a form your code will crash.

I wonder if that's why you were advised to be cautious with Me.Parent?

the solution to that very problem I discovered was to only inspect the text value of the object, its name, (every object has a name) and then check in the forms collection to see if it existed as a form. Then I could assign it to a form variable instead of an object variable. This overcame that problem.

Sent from my SM-G925F using Tapatalk

MajP · Jan 7, 2019

me.parent was a bad idea

That does not make sense to me because it is a proper pointer. There is a lot of folklore, like you have to set every object to nothing. Authors say things to be ultra conservative instead of explaining the rationale. The only issue is that the user needs to know what the parent of a given control is. The author may mean, that the parent of a control is not always the form. A strange one is a control on a tab. Its parent is the tab not the form; however, that control is not part of the tab's controls collection. So the control is not a "child" of the tab but its parent is the tab. I find that strange. Going the other direction there are some things that only can be referenced through the "child" control like a subform. You cannot get that through the forms collection.

always use Me![ControlName]

That, I would argue is a bad idea and I will provide rationale. You should always use Me.ControlName. With bang notation you have negated intellisense and will not be debugged if improperly typed. I type "me." then a letter or two and the proper name is always selected from the list. All controls are both a property of the class and also members or the control collection. Seems more direct to reference the property than reference the object through the collection. The other problem with Bang is that you cannot use a variable name to reference the control, like me.controls(someVariable).

Cronk · Jan 7, 2019

Its parent is the tab

Actually, the parent of a text box on a tab is the tab page, which in turn has the tab as its parent.

Dreamweaver · Jan 7, 2019

MajP said:
That, I would argue is a bad idea and I will provide rationale. You should always use Me.ControlName. With bang notation you have negated intellisense and will not be debugged if improperly typed. I type "me." then a letter or two and the proper name is always selected from the list. All controls are both a property of the class and also members or the control collection. Seems more direct to reference the property than reference the object through the collection. The other problem with Bang is that you cannot use a variable name to reference the control, like me.controls(someVariable).

Sorry have to disagree I have used Me![ControlName] for the last 25 years without any problems maybe I'm wrong but I don't have problems with dealing with controls on a form Hence you would use forms!formname!contolname
I may be wrong but thats how I learnt I'm not a pro I just do it because enjoy the challenge it gives me.

I have created at least 20 examples over the years never had any complaints with using it in them.

My way is if it's the form I use me![ControlName] if I'm in the forms module
If I want to go deeper I use me.Field If it's in the dataset for a form but I hardly ever use that method.

MajP · Jan 7, 2019

Actually, the parent of a text box on a tab is the tab page, which in turn has the tab as its parent.

Thanks for correcting. To make it more confusing for subform inside a subform control on a tab, the parent is the main form and not the page. However, for the subform control itself, the parent is the page.
So yes the a user could get it wrong if they are unaware of the parent, so the advice is cautious but not absolute.

Sorry have to disagree I have used Me![ControlName] for the last 25 years without any problems maybe I'm wrong but I don't have problems with dealing with controls on a form Hence you would use forms!formname!contolname
I may be wrong but thats how I learnt I'm not a pro I just do it because enjoy the challenge it gives me

I never said you were wrong, I simply argued why I thought it was a bad idea and provided rationale. Similarly, have have provided rationale why it may be advisable not to use the parent property if you do not fully understand what the parent of a control is. I am just not a fan of absolute statements, that do not have a support. The statement "Be cautious of using the me property on a control reference, because it is not always the form" is very different than "you should never use the parent property". There are a lot of things that work, but are not the best idea. The fact something works or you can make it work is not necessarily justification as being the best way. I can make spaces in table and field names work, lookups in tables work, multi value fields work, etc. Does not mean I would use them or recommend it.

Micron · Jan 7, 2019

I agree with Me.myControl name. While it was stated that an incorrect reference wouldn't be debugged, I prefer the term "when compiled". Try misnaming a control in code when you use !. Click to compile your change and it won't be resolved. Change the ! to . still with the wrong control name and compile your code again. If the incorrect name isn't caught, you have bigger problems, but I've never seen it fail. Further to having the advantage of intellisense, when coding, I key variable names in lower case while my variables almost always contain camel case. When the name is complete, I know it's wrong if it doesn't change case. It's a sort of intellisense, I think.

This might provide better insight on the operator !

https://bytecomb.com/the-bang-exclamation-operator-in-vba/

MajP · Jan 7, 2019

I prefer the term "when compiled"

Thanks, that is a better explanation.

I key variable names in lower case while my variables almost always contain camel case. When the name is complete, I know it's wrong if it doesn't change case. It's a sort of intellisense, I think.

Yep, that is exactly what I do. Purposely but in a wrong case and watch if it corrects itself.

Dreamweaver · Jan 7, 2019

MajP said:
You should always use Me.ControlName. With bang notation you have negated intellisense

I started with access before intellisense to me it's just a lazy way of programming but thats me All I know is me.field could relate to both the form and the underlying recordset so if you have a control that does not have the same name as the Controlsource name me. will reference the controlsource not the form field

MajP · Jan 7, 2019

to me it's just a lazy way of programming but thats me

I am going to guess that is just you. I have never heard that from anyone else. You probably do not want to start programming in Visual Studio where it is indents and formats for you, you will really hate that.

if you have a control that does not have the same name as the Controlsource name me. will reference the controlsource

I guess that is a true statement, but does not really make any sense. If I have txtBxlastname with the control source LastName. One would expect that you hav to reference it as me.txtBxLastName and not me.lastname. That is the reason many people do not use the default name. But that is no different in bang.
me!txtBxLastName and not me!lastName if you want the control. There is no difference.

me.field could relate to both the form and the underlying recordset

Not sure what you are saying, but do not think that makes sense.

Micron · Jan 7, 2019

me.field could relate to both the form and the underlying recordset

Exactly why you should not name a control and field the same. If I use a wizard to create a form, I go through each and every control to give them a name according to my convention. While I've only seen the error once (Ambiguous name detected) it was for that very reason. As soon as I changed the control name, no problem, so no, it was not because I had 2 controls or variables with the same name.

Seems that you can't be convinced , which is fine because you are, of course, free to stand firm on your convictions regardless.

MajP · Jan 7, 2019

I could be wrong, maybe other people do not like intellisense since there is an option to turn it off so there must be a reason. I just never heard anyone say so.

Dreamweaver · Jan 7, 2019

One of the examples I'm going to include is different ways of getting 2 forms working together.

One way I've never used but dont know why

My question is:

I have form 1 Main form and form 2 which is open dialog with a number of unbound fields for data entry now my question is can I pass all the entries on the dialog to some global variables then use the variables to update form 1 is there anything wrong with this method?

Dreamweaver · Jan 7, 2019

MajP said:
I could be wrong, maybe other people do not like intellisense since there is an option to turn it off so there must be a reason. I just never heard anyone say so.

It does come in handy when dealing with properties etc I'm a really bad speller so it does save me at times lol

Uncle Gizmo · Jan 7, 2019

MickJav said:
use the variables to update form 1

You can link controls on the calling form to controls on the called form (the popup form).

When the called form is closed, the calling form controls are updated.

Would need to know more, to give specific advice...

Sent from my SM-G925F using Tapatalk

Forms/controls Example (1 Viewer)

Well-known member

Attachments

Registered User.

Well-known member

Registered User.

Nifty Access Guy

Well-known member

Nifty Access Guy

You've got your good things, and you've got mine.

Registered User.

Well-known member

You've got your good things, and you've got mine.

AWF VIP

You've got your good things, and you've got mine.

Well-known member

You've got your good things, and you've got mine.

AWF VIP

You've got your good things, and you've got mine.

Well-known member

Well-known member

Nifty Access Guy

Similar threads

Users who are viewing this thread