Can I know which form opened the current form?

[JohnInDC]

I have a menu system that drills down by showing a "lower" menu form and hiding the "upper" menu form when the lower menu form opens.

I usually execute a Form.show in the lower menu form's unload method to make the upper menu form reappear when the lower menu form is closed.

Here's my problem...

I have a lower menu form that can be opened by several different upper menu forms, and I need to know which upper menu form to show when the lower menu form unloads.

How can I know which form opened the currently open form? Is there a property that stores this info? Or, can I pass a parameter or fill a global variable with the opening forms identity? If I were to pass a text value with the form name, how would I convert that to a Form.show call?

Thanks for your help!

John

 

[shakespeare5677]

You can always use a global variable, but that might get funky depending on how many forms are loaded. I would say add a public sub to the child form that will accept the parent form's name and show the form:

in child form:

option explicit
private strParentFormName as string

Public Sub ShowChild(ParentFormName as String)
     strParentFormName = ParentFormName
     Me.Show
End Sub

all that's left to do is call the sub from parent form: frmMyChildForm.ShowChild Me.Name

-Max

 

[BobRodes]

Shakespeare, it looks to me like your solution won't show the parent form at all. Me.Show will show the child form; the fact that the parent form is calling ShowChild is irrelevant.

Personally, I would set up a property in the child form that references the parent form. This can be as simple as a public variable; if you want to use property procedures there are plenty of threads explaining how. So:

'in the child form's code window
Public ParentForm as Form 'general declarations section

Private Sub Form_Unload
ParentForm.Show
End Sub

'in the parent form's code window
Private Sub ShowChild
With myChildForm
    Set .ParentForm = Me
    .Show
End With
End Sub

This will also allow you to do other things with the parent form from the child form's context, since you have a reference to it.

HTH

Bob

 

[shakespeare5677]

Understood, but I was going more for just knowing what the parent form was, which is what the argument accomplishes. Also, I personally do not like forms passed in any way shape or form unless absolutely necessary. The reason whey Me.Show was added was so that the parent form can treat ShowChild as another Show call, instead of having to call Show first and then ShowChild or something of the sort. Furthermore, depending on the type of the application and the flexibility required, I thought that perhaps having a select statement somewhere in a general module will make it easier for tasks common to some forms and not others. But then again, having the property is short and to the point - it's always nice to have alternatives.

 

[BobRodes]

Oh, I see. I've misunderstood your intention, sorry. As for the second thing:

If I were to pass a text value with the form name, how would I convert that to a Form.show call?

How would you do this? Personally, I might try passing the integer value of the forms collection, if I could find it easily. However, I don't really understand why you don't like passing form references. Not that you're wrong, but can you explain?

 

[JohnInDC]

Max & Bob,

Thanks very much for your help.

Your two answers were what I suspected was possible, either passing a value that told the name of the parent or passing an actual reference to the parent.

Max, I still don't see though what we would do with the name of the parent once we knew it. How do we use the text of the name to invoke the parent form's show method from the child form?

Thanks again,
John

 

[BobRodes]

Well, here is one way to do it:

dim i as integer
for i = 0 to forms.count - 1
   if forms(i).name = strPassedFormNameValue then
      forms(i).show
      exit for
   end if
next i

You could also use a for each loop. But personally I don't see why this is better than passing a form reference. I do this all the time, but Max may very well know something I don't.

Bob

 

[PCLewis]

A form name is not necessarily unique within an application where as a form's reference is always unique.

You may have a form in an application that can be instansiated multiple times and so would have the same name although in this case, the original poster did indicate that each form would only be opened once.

The main thing to remember when passing form references is to ensure that you set the variable containing them to nothing once you are done. You seem to be able to get away without doing this in VB but it's not very good practice in my opinion and can lead to memory leakage - especially if the parent holds a reference to the child and the child to the parent and if both parent and child are "closed". I might need to rerun a test I made a few years ago for that very thing in case this remembered fact is no longer valid

 

[PCLewis]

I ran a test that I have run previously and it appears that there is no longer a memory leak if form references are not emptied. The act of unloading a form might be enough now to dereference form variables so although I feel it's still good practice, it does not seem we are punished for it

 

[DrJavaJoe]

John, do a search in this forum for FormByName.


Two strings walk into a bar. The first string says to the bartender: 'Bartender, I'll have a beer. u.5n$x5t?*&4ru!2[sACC~ErJ'. The second string says: 'Pardon my friend, he isn't NULL terminated'.

 

[BobRodes]

<A form name is not necessarily unique within an application

PCLewis: to be sure, I just opened a standard exe app, added a form, and attempted to change form2 to form1. It won't let me. How do you get two forms with the same name in an application, or do I misunderstand what you're saying?

As for DrJJ's suggestion, that's a simple and well-crafted solution from strongm, in a situation where you couldn't use a form reference. I second his suggestion to read it, John.

Bob

 

[evalesthy]

This might help you:

thread702-1093778

 

[PCLewis]

BobRhodes: Here you go. I relaise the poster would not have been doing this however I still prefer not to rely on form names unless we know for certain they are only ever going to be instanciated once. In most Access applications this is the case so you are quite right.

Public Sub testForms()
  Dim frmOne As Form
  Dim frmTwo As Form
  
  Set frmOne = New Form_EquipmentComponents
  Set frmTwo = New Form_EquipmentComponents
  
  frmOne.Visible = True
  frmTwo.Visible = True
  
  MsgBox "form1 Name=" & frmOne.Name & ", form2 Name=" & frmTwo.Name
  
End Sub

 

[PCLewis]

Just to mention that some time in the evolution of Access they added an HWnd property for forms. This is available at runtime when the form is open. The Hwnd + formName will uniquely identify any form in an Access application. So passing a string and long vs passing a form reference I will still stick wioth the reference.

 

[BobRodes]

Oh, ok. Two form objects can reference the same form, and they will have the same name associated with them. That makes sense, in VB as well as Access VBA. I wanted to make clear that you weren't saying that you could have two forms of different names in an application.

I personally prefer to work with references when possible, too. As for duplicate names in the forms collection, though, strongm's solution (thread222-795815, among others) of selecting the most recent instance of any duplicate(s) seems entirely reasonable. Furthermore, there are some situations in which object references can't be used directly. Persisting between processes that don't have intersecting lifetimes, for example.

Bob

 

[PCLewis]

Could I revise my earlier statement to:
"A form name is not necessarily unique within a running application where as a form's reference is always unique"

To be fair, we were kind of discussing the forms collection at the time and I did mention in my second paragraph that I was referring to multiple instances

I noticed I posted VBA as an example after the fact but like you said it doesn't matter much. And yes, to be clear, I am agreeing that you cannot define two form classes with the same name in a VB or VBA application.

I think I am being fair in my guess that most VB and VBA users do not need to worry about multi-process applications so I don't consider the inability to pass form references over the process boundary to be significant. If I was writing such applications and if they had to be in VB then I would probably have a different preference such as yours.

 

[BobRodes]

It would seem we use the same approach, PCL. So Max, I'm curious to know why you feel differently, if you'd like to explain further.

Bob