Question about binding controls (1 Viewer)

[The_Doc_Man]

@MajP - Unfortunately, your assertion is at best partly true. All activated instances of forms normally have unique names in the Forms collection, some of which MIGHT be derived by adding an underscore and a number to the form's formal (non-loaded) name as defined in the AllForms collection. But if you step through the Forms collection by number (starting, of course, from 0 because it IS a collection), you COULD find a form with a number but a ZLS for a name. I've seen it once. And it is a son-of-a-witch to debug. I think, however, that only one form can have that name so if it would happen again, the next case would have "_1" as a name. Active forms CANNOT share names because it appears there is a uniqueness rule in force.

Think about it. If you want to be able to use the syntax Forms("xyz") to point to a single form yet you allow the XYZ form to be opened more than once for some bizarre reason, you could NEVER refer to the second instance unless it was qualified by something else. (Which it is - the underscore and a secondary instance number.) The same way that you can load the same table twice is the upper section of the query design grid, in which case the instance is qualified by underscore and a number.

 

[MajP]

@The_Doc_Man ,
NO, my assertion is not partly true it is 100% correct. There is no underscores or any other nonsense like that. EVERY form instance of the same class shares the same name in the FORMS collection. If you can make an example otherwise please do. I would like to see it. This is not something I made up, it is known. It is also something I know because I have experience in it and can see it with my own two eyes. If you do not believe my maybe Allen Browne is good enough for you

Microsoft Access tips: Managing Multiple Instances of a Form

How to open more than one instance of a form at once in a Microsoft Access database, and manage the instances independently of each other.

allenbrowne.com

Or this example may show you
Also this is not similar to dropping a second "instance" of a table or query in design view. That is apples and pears.

Select multiple names and open as many instances of the same form. Then hit get form names. If you find a ZLS or underscored get back to me. Thanks.

 

[Galaxiom]

You keep saying nameless
What do you mean by that? Do you mean not unique? All form instances of a form class share the same name, so it definitely has a name it is just not unique.

My bad. Poor choice of terminology. The instance generated by referring to Form_formname when the form is not loaded does of course have the Name property.

What is missing is the Item name in the Forms Collection. It has a numbered item index but AFAIK the instance cannot be referred to with the syntax that works for properly instantiated Forms.

Forms.Item("formname")

I would be impressed if anyone can find an Item name that works with these phantoms. Unfortunately, unlike a Dictionary, the Item names in a Collection cannot be enumerated.

It is easily tested. Just run this Sub and look in the Immediate Window. (Of course someform must exist and have an associated Module.)

Sub test()
Debug.Print [Form_someform].Name
Debug.Print Forms.Count
Debug.Print Forms(0).Name
Debug.Print Forms.Item("wish I knew").Name
End Sub

BTW Before you try, I can tell you it isn't "Form_someform" or a ZLS.

 

[Galaxiom]

@MajP - Unfortunately, your assertion is at best partly true. All activated instances of forms normally have unique names in the Forms collection, some of which MIGHT be derived by adding an underscore and a number to the form's formal (non-loaded) name as defined in the AllForms collection. But if you step through the Forms collection by number (starting, of course, from 0 because it IS a collection), you COULD find a form with a number but a ZLS for a name. I've seen it once. And it is a son-of-a-witch to debug. I think, however, that only one form can have that name so if it would happen again, the next case would have "_1" as a name. Active forms CANNOT share names because it appears there is a uniqueness rule in force.

Think about it. If you want to be able to use the syntax Forms("xyz") to point to a single form yet you allow the XYZ form to be opened more than once for some bizarre reason, you could NEVER refer to the second instance unless it was qualified by something else. (Which it is - the underscore and a secondary instance number.) The same way that you can load the same table twice is the upper section of the query design grid, in which case the instance is qualified by underscore and a number.

I suspect Docman has used "name" ambiguously in the same way I have and is also referring to the Item name.

I have not explored the Item names of multiple instances of Forms but I agree there must be some differentiation in the collection. I'm not sure that he literally means they are designated formname_1 like the table alias example he gave, just conceptually.

I'm suspecting it might be more like the names of the hidden queries generated by SQL command RecordSources and RowSources etc that can be seen when digging around in System tables. I expect the form instances are only in RAM with vanishingly little hope of guessing their Item name.

 

[MajP]

I have not explored the Item names of multiple instances of Forms but I agree there must be some differentiation in the collection. I'm not sure that he literally means they are designated formname_1 like the table alias example he gave, just conceptually.

I'm suspecting it might be more like the names of the hidden queries generated by SQL command RecordSources and RowSources etc that can be seen when digging around in System tables. I expect the form instances are only in RAM with vanishingly little hope of guessing their Item name.

@Galaxiom,
I am pretty certain there is no secret hidden name stored somewhere to manage a form instance. That is why all the Access Gurus, Allen Browne, Litwin and Getz, and every other MSDN example has a user defined collection to store the HWND and manage instances by that. The Allen Browne link I posted gives some pretty good explanation.
The behavior that you pointed out is confusing and is unique to Access AFAIK. Like you said simply by instantiating and referencing an instance of the class it activates an instance in a hidden mode. Since you cannot see it and it goes out of scope no one realizes that behavior. Even in Excel this does not happen you can instantiate an instance of a form class and it does not automatically activate. Same in .NET. So your point of not referencing a form or report by the class is good advice, because of these things that happen that you are unlikely to even realize. You used to see this done a lot for some reason, I have not seen that done for years. In the early days you could not do multiple instances so maybe it made more sense.

 

[Isaac]

This all seems like splitting hairs. I'm going to continue to refer to forms (sometimes) by Form_Formname.[dot] for the intellisense it gives me until anybody articulates a very good reason why not. And I haven't seen one in 15 years +

 

[gemma-the-husky]

Isaac and theDBguy are right. If you define the .RecordSource dynamically at run-time, you are at least implying that there is no .RecordSource in place. If so, there is nothing for any of the Access internal automation to find during design phase.

You can still do this dynamically, perhaps during a Form_Load event, but it will not be enough to just define the .RecordSource at that time. You will also have to go through the controls to set each .ControlSource or .RowSource (as appropriate for the control type.)

Instead of changing the form's RecordSource, you can switch in a different subform completely, using the SourceObject property.

 

[gemma-the-husky]

The Access Cookbook demonstrated a way of opening multiple instances of the same form. It managed a collection of forms, which it did by referring to the forms HWND as a string, in the way @MajP described. eg, you have two customer forms open, so you can compare settings between the two. So the collection of customers forms does this,

So the new form's name is indeed HWND & "", to treat it as a string.

colForms as New Collection

Sub NewForm
dim frm as form

set frm = new Form_frmCustomers
colForms.add  Item:=frm, Key:=frm.hwnd & ""  'required to make it a string, it says

'with more form management stuff to add a caption to the new form, position it and and finally display it.

End Sub

 

[The_Doc_Man]

I suspect Docman has used "name" ambiguously in the same way I have and is also referring to the Item name.

True. After last night's exchange, I thought about it a bit more. It happened when I took over an Access DB created by a colleague who was a great system admin but didn't know JACK about databases - so he built one, the department started using it, and then the bugger left for a job closer to his home town. So my boss asked if anyone in the department knew anything about Access and (OKAY, I WAS NAIVE!!!) I said I did. You can put two and two together here and come up with the right answer, I'm sure.

Once I cleaned up how he launched things from his home-grown "switchboard" (that really wasn't a switchboard), the problems disappeared. But for a while things were just "odd" in that changes made to something at run-time didn't seem to stick around even though the syntax appeared right. Because the were going to the wrong form.

Just to be clear, I'm not a "true" expert. You do know the meaning of "expert" don't you?

According to physicist Niels Bohr, "An expert is a person who has made all the mistakes that can be made in a very narrow field."

Or my own favorite, for which I've forgotten proper attribution: "An expert is someone who recognizes his mistakes the next time he makes them."

I'm not a "true" expert because I haven't reached the pinnacle of that appellation. I have a few original mistakes still waiting for me.

 

[MajP]

The Access Cookbook demonstrated a way of opening multiple instances of the same form. It managed a collection of forms, which it did by referring to the forms HWND as a string, in the way @MajP described. eg, you have two customer forms open, so you can compare settings between the two. So the collection of customers forms does this,

So the new form's name is indeed HWND & "", to treat it as a string.

I posted earlier the Allen Browne explanation to do this and a demo using this so one can see it work.

 

[Minty]

My favourite definition :
"The expert is the person in the room with the most knowledge on the subject at hand."

Which could, of course, be the equivalent bugger all squared.
In this particular room however, I wouldn't like to say

 

[Pat Hartman]

I prefer using querydefs as the RecordSource. It allows me to use the query in multiple places. I don't like writing static SQL in VBA. You have to when the SQL is dynamic but static SQL should be a querydef. And finally, although you can open the QBE from the Form/Report's RecordSource and create an SQL string and save the string, I don't do this because there is a bug that can cause the SQL string to be truncated and of course the bug only rears its ugly head when the string is long and complex.