Clicking multiple Command button in Single click

[vivekt]

I have a Form with 4 Command buttons in that 3 command Buttons were used to send email for a specific area based on query with filter.

I am trying to use the 4th Command button which when clicked will click on 3 buttons at once sending 3 emails. Is there any way to achieve it through Access . please help me know?

 

[missinglinq]

Just Call each button from the 4th Button:

Private Sub Button4_Click()
  Call Button1_Click
  Call Button2_Click
  Call Button3_Click
End Sub

using your actual button names, of course.

Welcome to Access World!

Linq ;0)>

 

[isladogs]

Linq beat me to it.
The Call command can be omitted and it will still work fine

 

[Uncle Gizmo]

It's not considered good practice to directly call the code associated with a control.

The correct way to do it would be to create a function or subroutine for each command button and then call those routines from the relevant command button, then call those routines from the fourth button.

Sent from my Pixel 3a using Tapatalk

 

[isladogs]

It's not considered good practice to directly call the code associated with a control.

The correct way to do it would be to create a function or subroutine for each command button and then call those routines from the relevant command button, then call those routines from the fourth button.

That's a perfectly valid method of doing this.
However, I see nothing wrong with calling existing code. In what way us it bad practice?

 

[Uncle Gizmo]

In what way is it bad practice?

I didn't say it was bad practice I said it was not considered good practice. There's a subtle difference.

It's one of those things we all do from time to time. However the correct way to structure code that is called from multiple places is to separate your code out into its own function or subroutine.

Sent from my Pixel 3a using Tapatalk

 

[missinglinq]

I didn't say it was bad practice I said it was not considered good practice...

I didn't know you were a politician, Uncle Gizmo!

Linq ;0)>

 

[isladogs]

I didn't say it was bad practice I said it was not considered good practice. There's a subtle difference.

It's one of those things we all do from time to time. However the correct way to structure code that is called from multiple places is to separate your code out into its own function or subroutine.

Of course I agree about creating procedures that are going to be called from multiple places. However, in this case the code is being called from just 2 places - the original button and one other button. The amount of code required is the same by either method.
In fact, two places is not the same as multiple places -there's a subtle difference

 

[Uncle Gizmo]

I didn't know you were a politician, Uncle Gizmo!

Linq ;0)>

I'm getting Mellower with age!

I was a bit stuck when Colin challenge me, I thought, well, why not? I was always told not to do it, right from when I first started, so Colin had me wondering if it was one of those old wife tales things which propagate. When I thought about it properly, I realised it's not that you shouldn't call a Controls Code directly (See Note Below), it's that Code should be modular, therefore if you are calling Code which is within a controls event routine, then you're not structuring your VBA correctly.

There are other possible old wives tales:-

Function or Subroutine
I have often been criticised for using a function where a subroutine would suffice, however I find it more convenient to develop with functions. For some reason this practice upsets some people! I'm not too bothered about it because there are some glaring inconsistencies in MS Access, in that there are certain times you have to use a function. If you try to use a subroutine it won't work! You have to convert your subroutine into a function. To my mind, if MS Access forces you into a position where you have to convert a subroutine into a function, then I can't see any good reason why I should worry about using a Function.

Global Variables
This is another thing I've always been told:- Never use "Global Variables" - This can go wrong that can go wrong. Again it's something we all do! Is it an old wives tale? I suspect it's more akin to that there are better ways to do it, use a function, or a property, in other words, use a structure which gives you the ability to add error checking and handling of the variable. It's more like if you have a "Global Variable", consider changing it to something more robust. And the old wives tale is never use "Global Variables"!


Note:-
I was always told "bad things will happen" when calling a Controls event routine from somewhere else. - It is unsafe for some reason. However that does have the distinct possibility of being some sort of old wives tale. Not too sure. I wonder if it's a practice, a carryover from Pre MS Access developers. There must have been such people, probably VB6 programmers or other languages, and they brought their experience with them, which was applied (rightly or wrongly) to MS Access.

 

[Uncle Gizmo]

Regarding the Function or Sub issue, it does have some bearing on the original thrust of this thread, of where and when you should call code. In other words not calling a controls event code from somewhere else..

Test a function
You can do a quick test yourself if you create a form, add a textbox to it, add a function for example:- fMyFunction() which just pops-up a message box. Now in the text box events, I reckon the best one would be the onclick event, add a call to the function like this:- = fMyFunction() then save, close & reopen the form. Click on the text-box and the message box will pop up saying whatever you told it to say!

Test a subroutine
Now if you go back into the forms code module and change that function into a subroutine, then go back and click on the text box you will get an error message. In other words you are not allowed to run a subroutine from a controls event.

Cannot call the onclick event from the onclick event.
Imagine what would happen if you tried to run the "Textbox" onclick event from the onclick event! I reckon that may well be the reason that you have subroutines and functions, it is a method of isolating the routines associated with controls from general routines created by the user.

Smokin!
Now I haven't tried this, as I don't really recommend you try it but what would happen if you converted that subroutine back into a function, but now have that function call that text box onclick event! If your computer starts overheating and spouting flames don't blame me!

 

[June7]

Minor point about verbiage.

Can call a subroutine from control's event.

Can't call a subroutine from control's event property.

Functions can be called from macros, queries, properties (ControlSource and events) but not subroutines. So this is where Access forces use of functions.

 

[Deleted member 147267]

In other words you are not allowed to run a subroutine from a controls event.

Most control events are subs, so I wonder if that's what you really meant to say. I'm going to suggest that this has more to do with what you can assign a procedure to when that procedure is not a built in event, and the assignment has to be a function. No idea why. It's probably common knowledge that only a function can be called from a menu, toolbar or ribbon. Furthermore, only a function can be assigned to a control event where the procedure for that event is not a built in one.

Another option for the original question would be the same function that accepts the control name as an argument and acts accordingly - not necessarily would I do that for this case. There may be a better design approach before we got to this stage; e.g. a combo to make some selection. Anytime I see multiple controls being used for basically the same thing, my design hat starts to twinkle.

 

[Mark_]

To add to Uncle's post, the only reason I've been told "Don't do it" is because you want to make sure that each control's code executes properly. If you have a set of functions that return true OR false consistently when they complete properly you can use them from each control as well as from ONE control that verifies each has done its job. This normally comes up when button A does something and button B needs button A's code to have finished correctly. Think "A saves a report to disk". B Emails the report A created. If A fails, you should skip having B execute.