Command Button

[Wavequation]

I have a routine I'd like to run when a form closes, that associated with a
command button on another form. Can I trigger the event associated with the
command button by using VBA attached to the onclose event of the first form?

 

[Stuart McCall]

I have a routine I'd like to run when a form closes, that associated with a
command button on another form. Can I trigger the event associated with
the
command button by using VBA attached to the onclose event of the first
form?

Make the sub Public, ie:

Public Sub Command0_Click()

and call it from the other form like:

Form_OtherFormName.Command0_Click

 

[Stuart McCall]

Make the sub Public, ie:

Public Sub Command0_Click()

and call it from the other form like:

Form_OtherFormName.Command0_Click

Addendum: Replace OtherFormName above with your first form's name (no quotes
or anything). "Command0_Click" ought to appear in the intellisense list as
you type.

 

[Dirk Goldgar]

I have a routine I'd like to run when a form closes, that associated with a
command button on another form. Can I trigger the event associated with
the
command button by using VBA attached to the onclose event of the first
form?

Only if you make the event procedure from for the command button Public
instead of Private. By default, event procedures are Private, as in this
example Sub header:

Private Sub cmdMyButton_Click()

Before you can call this button's event procedure from another form, you
have to change "Private" to "Public":

Public Sub cmdMyButton_Click()

After that change has been made, you can call the procedure from another
form, but you need to qualify it with a reference to the form containing the
procedure (which must be open). For example, if cmdMyButton is on form
"frmButtonForm", and you want to call it from the Close event of form
"frmClosing", then -- provided the event procedure is declared Public as
above -- you can do it with code like this in frmClosing:

'----- start of example code -----
Private Sub Form_Close()

If CurrentProject.AllForms("frmButtonForm").IsLoaded Then
Call Forms!frmButtonForm.cmdMyButtonClick
End If

End Sub
'----- end of example code -----

Depending on your application's logic, you may or may not need the test to
see whether frmButtonForm is open before attempting to call its
cmdMyButtonClick procedure.

 

[Dirk Goldgar]

Make the sub Public, ie:

Public Sub Command0_Click()

and call it from the other form like:

Form_OtherFormName.Command0_Click

Stuart, I would argue against using this notation, for two reasons:

1. If there might be more than one instance of the form loaded, you don't
know which instance's procedure will be called, and

2. If the form is not currently open, this type of reference will load a
hidden instance of it, which is usually not the desired behavior.

Many people are not even aware that calling a procedure by referring to the
form's class module forces the form to be loaded if it isn't already. I've
seen apps that have several hidden instances of forms in the background,
unbeknownst to the developer.

I recommend using standard form notation for this purpose; e.g.

Forms!TheFormName.Command0_Click

That way, if the form is unexpectedly not open, an error will be raised and
can be handled.

 

[Stuart McCall]

Comments inline:

Stuart, I would argue against using this notation, for two reasons:

1. If there might be more than one instance of the form loaded, you don't
know which instance's procedure will be called, and

This is still an issue when you refer to the form via the forms collection,
isn't it?

2. If the form is not currently open, this type of reference will load a
hidden instance of it, which is usually not the desired behavior.

The OP sounds like he _knows_ the form is open. Still I take your point.

Many people are not even aware that calling a procedure by referring to
the form's class module forces the form to be loaded if it isn't already.
I've seen apps that have several hidden instances of forms in the
background, unbeknownst to the developer.

I recommend using standard form notation for this purpose; e.g.

Forms!TheFormName.Command0_Click

That way, if the form is unexpectedly not open, an error will be raised
and can be handled.

That's a fact. You're right. I suppose it depends who's writing the code. I
use that direct notation (my terminology) quite a bit, without problems.
Maybe it's not the best practise to recommend it here, however.

 

[Dirk Goldgar]

This is still an issue when you refer to the form via the forms
collection, isn't it?

No, because there can only be one named instance of the form in the Forms
collection. Any other, non-default instance can only be referred to via an
object variable that has been set to point to it. So a reference via
Forms!FormName always refers to the default instance.

The OP sounds like he _knows_ the form is open.

True, and in such a case, and when there will only be one instance open, the
class-module reference is fine. I just worry about inexperienced people
getting in the habit of using that method without understanding its
ramifications.

I suppose it depends who's writing the code. I use that direct notation
(my terminology) quite a bit, without problems.

Of course. I'm not worried about *you*.

 

[Stuart McCall]

No, because there can only be one named instance of the form in the Forms
collection. Any other, non-default instance can only be referred to via
an object variable that has been set to point to it. So a reference via
Forms!FormName always refers to the default instance.

Well I learned something there. I must confess to never having employed the
multiple instance technique, so I didn't know any of that. (I know, I need

True, and in such a case, and when there will only be one instance open,
the class-module reference is fine. I just worry about inexperienced
people getting in the habit of using that method without understanding its
ramifications.

I understand and agree. If ever I mention this again I'll be sure to provide
a warning too. Thanks for setting me straight.