Call a button click on another form (1 Viewer)

Orinoco · Feb 6, 2006

Hello everyone!

I need to call the button_click procedure for a button on a form (button1), from another form, if you see what I mean!.

Basically the user opens form1. They click a button which opens form2. Once they have finished on form2 they press the close button, which is the point where I need to call the button1_click procedure on form1.

I imagine it's something like this:

Call Forms![frmForm1]![button1]![Click] or
Call Forms.[frmForm1].[button1_Click()]

But no matter what syntax I try it just won't work!
They're very basic forms, with only 2 buttons on and basic commands.

Any help appreciated!

Thanks

Bodisathva · Feb 6, 2006

try:

Code:

Call Forms!FormName.buttonName_Click

Orinoco · Feb 7, 2006

Bodisathva said:
try:

Code:

Call Forms!FormName.buttonName_Click

I tried that and got:

Compile error Expected: . or (

I replaced the ! with a . and this time got:

Run-time error '438': Object doesn't support this property or method.

Any other ideas?

RuralGuy · Feb 7, 2006

To start, your Click procedure needs to be Public rather than Private. Then the following syntax will work:

Call Forms.frmForm1.button1_Click

Using your FormName and ControlName of course!

Orinoco · Feb 8, 2006

RuralGuy said:
To start, your Click procedure needs to be Public rather than Private. Then the following syntax will work:

Call Forms.frmForm1.button1_Click

Using your FormName and ControlName of course!

That's the one! Thanks!!

RuralGuy · Feb 8, 2006

Glad to help.

cyberman55 · Dec 26, 2018

Just a late enhancement if anyone stumbles on this. To call from another form a public sub on a subform, this works:

Call Forms("formName").Controls("subfromControlName").Form.NameofPublicSub

Uncle Gizmo · Dec 26, 2018

I can't think of any reason that you should call a Command Button on another Form, or any control really. Also I believe it is considered bad practice, Why, I don't know, but I think this is probably because it can have some unforeseen consequences. What I do know is there's absolutely no need to do it. Your command button will activate code within a code stub in the code behind the form. All you do is take any code that is in the command button code stub, put it into its own Public subroutine/function and call that... Now you don't have to make your command button code public, and you can call the new function/subroutine from The command button and anywhere else...

cyberman55 · Dec 26, 2018

Not that easy when the code is long and refers to other controls on the form. This works fine.

BrianDP · Jan 19, 2021

Uncle Gizmo said:
I can't think of any reason that you should call a Command Button on another Form, or any control really. Also I believe it is considered bad practice, Why, I don't know, but I think this is probably because it can have some unforeseen consequences. What I do know is there's absolutely no need to do it. Your command button will activate code within a code stub in the code behind the form. All you do is take any code that is in the command button code stub, put it into its own Public subroutine/function and call that... Now you don't have to make your command button code public, and you can call the new function/subroutine from The command button and anywhere else...

Well Giz, I'll tell you why I'm doing it.

It's a form I wrote that would normally be controlled by humans, but in this case I'm controlling it from a timed form that sort of does the actions of a human every day at certain times. I would just copy the code from underneath this button into this code, but then I'd have two copies of the code to maintain. I suppose the best thing to do would be to make a function out of it and have both places call that function, but I'm just being lazy!

How's that for an explanation?

MajP · Jan 19, 2021

The answer is already posted in this thread, but here is how I would do it to make it cleaner.

You do not have to do this but it is cleaner and easier to read IMO.
Assume in your form you have a click event. By default as mentioned they are private (you could simply make them public)

Code:

Private Sub cmdOK_Click()
   Some code
End Sub

Again just for clarity I would keep the click private and move the code from the click into a public procedure

Code:

Private Sub cmdOK_Click()
    SomeProcedure
End Sub

Public Sub SomeProcedure()
  Some code
end Sub

To call this code from outside the form assuming the form is open

Forms("YourFormName").SomeProcedure

It is a procedure in a class module so must be called through an instantiation of the class.
See RuralGuy's post from 2006 which provided the answer.

Uncle Gizmo · Jan 19, 2021

MajP said:
See RuralGuy's post from 2006 which provided the answer.

I don't think it's a good idea to make a click procedure public. There is never going to be a case where you would have to. Just place the code into a separate procedure.

Uncle Gizmo · Jan 19, 2021

BrianDP said:
I would just copy the code from underneath this button into this code, but then I'd have two copies of the code to maintain

Not if you put the code in a separate procedure and call that from both places.

MajP · Jan 19, 2021

I don't think it's a good idea to make a click procedure public. There is never going to be a case where you would have to. Just place the code into a separate procedure.

You do understand there is 0 fundamental difference in the two approaches? You make the click public or move the click code into a public procedure it is the same thing. The only difference is that the latter IMO is easier to read since it is more common. The only "bad idea" of making the click public is readability. Making the click public makes nothing more or less protected.
My point was that RuralGuy showed how you call a procedure in a form through the instantiated form instance.
Call Forms.frmForm1.button1_Click
However the notation is incorrect and would not compile. Should be
Call Forms!frmForm1.button1_Click

Uncle Gizmo · Jan 19, 2021

MajP said:
You do understand there is 0 fundamental difference in the two approaches?

Why are the procedures private?

MajP · Jan 19, 2021

Why are the procedures private?

You should always limit the lifetime and scope of variables and procedures. That is good coding practice. Form procedures DEFAULTed to private because most likely in a form you would make procedures scoped to be accessible within the form only. But if you choose to make them public you can. So if you make the original event procedure public or move the code into a standalone procedure, the code is public makes no difference.

gemma-the-husky · Jan 19, 2021

Axiomatically, I would have thought it better to keep the actual click button private to the form, and provide access to it via a specially created method. It might be the same thing in practice, but it's a good habit to develop, I think. You might even decide in time that you want the public procedure to be slightly different to the click handler.

MajP · Jan 19, 2021

@gemma-the-husky,
I think you are reiterating what I have already said. I suggested you should do this for readability, but there is nothing "wrong" with not. My issue is saying something is a good idea or bad idea without context. The best example is that people will adamantly say that you have to set object variables to nothing all the time, but few can explain why this is true or not true. If they do provide reasons, most of them are wrong. Fewer can explain those very rare cases when you do need to. I am not a fan of doing something all the time just to account for the .5% case. I rather understand the .5% case and code for that.

So there are positive reasons to move this code into a separate procedure.

1. It is always good idea to move most code out of an event procedure, especially if that event procedure code does more than one thing. This allows you to call the same procedure from more than one event, which is common. This also allows you to call that procedure from multiple events, but these events can call more code or do something in addition.
2. IMO It is more readable. IMO it looks weird to call an event procedure even though it is fully legit. In fact I would never do it, but others do.
3. As you mentioned it adds flexibility. Pretty much the same as what I said in 1. You could easily change the scope, change the arguments, and modify the event procedures to do additional things.

It is a good idea because of the above reasons, but nothing "bad" happens if you do not.

Call a button click on another form (1 Viewer)

Orinoco

Guest

Bodisathva

Registered User.

Orinoco

Guest

RuralGuy

AWF VIP

Orinoco

Guest

RuralGuy

AWF VIP

cyberman55

Registered User.

Uncle Gizmo

Nifty Access Guy

cyberman55

Registered User.

BrianDP

New member

MajP

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

Uncle Gizmo

Nifty Access Guy

Uncle Gizmo

Nifty Access Guy

MajP

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

Uncle Gizmo

Nifty Access Guy

MajP

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

gemma-the-husky

Super Moderator

MajP

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

Similar threads

Users who are viewing this thread