Way to know form name that opens a particular form

[Uncle Gizmo]

I attached the sample db here, for easy evaluate the issue

I tested the sample database you provided, and as far as I can tell it works in The Manner that you want it to. See attached see YouTube video for my demo of it working correctly. "your sample database!"

tblFootPrint Combo Box Matching​

 

[mike60smart]

Please can anyone tell me why you want a Main Form based on tblFootprint with a Subform based on the same table?

What would be the purpose?

 

[Edgar_]

I see that my post with the right way to approach this has been ignored. Post #8 by me tells you how to solve this.

So this will requery your combo selectively:

Private Sub Form_Close()
    If InStr(Me.OpenArgs, "FrmA1") Then
        Forms.FrmB1.Form.FrmA1.Form.Cbx_Footprint.Requery
    ElseIf InStr(Me.OpenArgs, "FrmB1") Then
        Forms.FrmB1.Cbx_Footprint.Requery
    End If
End Sub

 

[The_Doc_Man]

First, I looked up the ListItemsEditForm property. It says nothing about having an automatic OpenArgs tie-in. So if there WAS an open args entry, it was done manually and that means from the call that invoked the form.

However, you DO NOT CARE which form called which form. Look up the two events called _Activate and _Deactivate - which come into play when focus changes from one form to another for any reason. When focus re-enters a form, do the requery in the (still open) calling form's Form_Activate event. Let the closing form (Form C in the example) just go back to sleep.

You were trying to make form C do something nice for the form that opened it but it is a pain in the patootie to actually determine (via system calls) which form called you, and yet the suggestion to pass that information via OpenArgs seems to be met with some friction. The easiest choice is to have that calling form do its own requery, which you can do from a Form_Activate event.

Form.Activate event (Access)

Office VBA reference topic

learn.microsoft.com

Excerpt from that link: "When you switch between two open forms, the Deactivate event occurs for the form being switched from, and the Activate event occurs for the form being switched to."

So you DO NOT CARE how form C got called and you don't care whether A or B called C or you ran C directly for some reason. Put the combobox.Requery in the _Activate event for each of A and B. At worst, this causes 1 extra .Requery when you open the form for its first use. AND if you were to directly open C (for testing, e.g.) it doesn't have to look for something that wasn't there in the first place.

 

[Mike Krailo]

I think babycat has successfully drove some of us mad. I'm with Uncle Gizmo in that the provided sample database works perfectly fine. But the whole example makes no sense whatsoever. Why is there just one table and a main form and subform based off the same table???? And the combo boxes are the exact same? mike60smart was smart enough to point that out already. I think it's all an unrealistic and non sensical sample database.

So if baby cat would give us a better example database that matches the real one a little closer, then we help. What Doc and Moke123 said makes the most sense to me.

 

[mike60smart]

Glad someone agrees with me.

 

[Edgar_]

First, I looked up the ListItemsEditForm property. It says nothing about having an automatic OpenArgs tie-in

If it's undocumented then it's just another silly thing they missed, lucky me I did not read any documentation, I debugged the app with the Locals window and the OpenArgs had that information. Lots of undocumented behavior comes from debugging.

So if there WAS an open args entry, it was done manually and that means from the call that invoked the form.

What happened in your test?

As for the Activate/Deactivate events, they might be another way to solve this particular scenario, but that doesn't mean the passed OpenArgs string will stop existing, it's there for a reason. Now, since the "automatic" OpenArgs property only shows the parent form's name and the combobox that called it, that might be a drawback... but, is it?

Anyway, had the OP debugged his app, this thread would probably not exist, but it does seem surprising that nobody mentioned it.

 

[Edgar_]

I'm with Uncle Gizmo in that the provided sample database works perfectly fine.

On my end, if you call the form from the subform's combobox edit button, the parent form's combobox does not show the last entered value. So it does require a requery.

 

[The_Doc_Man]

What happened in your test?

Once I read the documentation, if it doesn't tell me that it explicitly adds an OpenArgs reference, I don't make assumptions, and I don't have time to test things for which there are easier solutions anyway. Our time is limited and if I waste my time following a line of programming that is more convoluted than is really necessary, I do a disservice to the others I might later have the chance to help. So... What test would that be, Edgar? How about the test of reason?

 

[Pat Hartman]

I can't set form OpenArg of formC since it is opeing from combobox click.

That makes no sense. Use Me.Name to put the form name in the OpenArgs

 

[Babycat]

Seems my suggestion has been totally ignored. Not going to waste any more of my time so going to drop off this thread. Good luck finding an alternative solution

Hi CJ

Really sorry for that, I have tried to understand your suggestion but I was not sure i understand it hence I dont know how to implement it

 

[Babycat]

I tested the sample database you provided, and as far as I can tell it works in The Manner that you want it to. See attached see YouTube video for my demo of it working correctly. "your sample database!"

tblFootPrint Combo Box Matching​

I dont know why it is not working at my side. Seem Edgar can replicate the issue.
Sorry about bad sample db, it not what my real project. I just want to make a demo the issue..
How is about your db, Nifty? can you remove the button "Edit combo list" and open formC from combobox?

 

[Babycat]

@Edgar.
Yeah, sorry again, I was not testing out your suggestions.
I am surprise the formC OpenArg telling us about the form opened it.
Glad to clearly distinguish formA and formB in its openarg

Thank you very much again.

 

[Edgar_]

That makes no sense. Use Me.Name to put the form name in the OpenArgs

Pat, @Babycat is opening the form through the ListItemsEditForm functionality of the form, a property viewed in the Data tab of the form.

Once I read the documentation, if it doesn't tell me that it explicitly adds an OpenArgs reference, I don't make assumptions, and I don't have time to test things for which there are easier solutions anyway. Our time is limited and if I waste my time following a line of programming that is more convoluted than is really necessary, I do a disservice to the others I might later have the chance to help. So... What test would that be, Edgar? How about the test of reason?

I disagree with "reason" being enough test. As Carl Sagan says in his speech about Man in his arrogance "Common sense intuition can be mistaken, our preferences don't count".


@Babycat Was the OpenArgs enough to approach your issue?

 

[Babycat]

So you DO NOT CARE how form C got called and you don't care whether A or B called C or you ran C directly for some reason. Put the combobox.Requery in the _Activate event for each of A and B. At worst, this causes 1 extra .Requery when you open the form for its first use. AND if you were to directly open C (for testing, e.g.) it doesn't have to look for something that wasn't there in the first place.

Hi The Doc Man

@mike60smart has reccomended similar solutions which works. My issue was solved right away on his post #2. But then I am trying to find better solution which only do requery when neccessary, and end-up with the new goal of how to know which form open which form.

Thank you very much for your informative replies.

​

 

[CJ_London]

Really sorry for that, I have tried to understand your suggestion but I was not sure i understand it hence I dont know how to implement it

So your solution is to ignore it completely rather than asking for clarification. This is post 56 for a problem that was solved in post #2

 

[Babycat]

@Babycat Was the OpenArgs enough to approach your issue?

Yes, definitely.
I use OpenArgs quite often, but i have to set its value manually. I thought it was blank if we dont touch it...

 

[Babycat]

So your solution is to ignore it completely rather than asking for clarification. This is post 56 for a problem that was solved in post #2

In fact, many proposed solutions. I was also missed Edgar solution about using OpenArgs until he makes "clearly nice pictures" to point out what I missed, his solution make me learn new things.
May you also elaborate your proposed solution, so that I and other new member can learn it then?

 

[moke123]

Just to add another option.
You seem to want your cake and eat it too by not having to code each control but still cover all the bases.

Not tested extensively but this should requery all listboxes and comboboxes on any open form and their subforms with one call.

Public Sub RequeryOpenObjects()

    Dim frm As Variant
    Dim ctl As Control
    Dim ctlSub As Control

     On Error Resume Next
  
    For Each frm In CurrentProject.AllForms
  
        If CurrentProject.AllForms(frm.Name).IsLoaded Then
      
            For Each ctl In Forms(frm.Name).Controls

                Select Case TypeName(ctl)
      
                    Case "ComboBox", "ListBox"
                  
                        ctl.Requery
      
                    Case "Subform"
                
                        For Each ctlSub In ctl.Form.Controls
                      
                            If TypeName(ctlSub) = "ComboBox" Or TypeName(ctlSub) = "ListBox" Then
                      
                                ctlSub.Requery
                              
                            End If
                        Next

                    Case Else

                        'do nothing

                End Select
      
            Next
          
        End If
      
    Next

End Sub

 

[ebs17]

@Edgar_:
In the example, the gross clumsiness remains that the name of the control for the subform is the same as the name of the source object.
For a requery, the subform must be addressed differently than a main form. So you will fail on this path.