I have a form with a few buttons. I want create a button which will execute all the buttons one after the other, after each function of the buttons has completed. Also, I would like to change the colour of the buttons to show which button is being executed. How do I do this?
A:
Private Sub myUltraGroupingButton_Click()
Call cmdButton1_Click()
Call cmdButton2_Click()
Call cmdButton3_Click()
Call cmdButton4_Click()
End Sub
If you want to automate this and if it's a Form, you would need to iterate over Form.Controls. If it's a worksheet, I think you would need to use Worksheet1.ListObjects
Atmocreations
2009-11-10 10:32:55
i should iterate it in order for the command to excecute after each one has finished or?
tksy
2009-11-10 10:40:03
@Atomcreations, please either say what version of Access allows you to change the back colour for command buttons, or change your code to show forecolor :)
Remou
2009-11-10 12:11:40
argh. sry, i've been thinking about Excel...
Atmocreations
2009-11-10 21:06:04
This is a common bad practice. Best practices for a number of reasons are to split the code out from the events themselves so they can be called from other areas of the code. An event on one object shouldn't raise an event on another object.
BenAlabaster
2009-11-10 21:17:49
Calling events from other events is a bad practice and should be avoided.
BobTheBuilder
2009-11-10 22:51:27
I don't think it's that bad a practice, though I don't do it in my own code (my reason is that I've found that I have trouble remembering the exact syntax for calling the events). There is not real difference in terms of execution between a sub that is fired by an event and a standalone sub -- it's just a subroutine in either case, and there's nothing special about a sub defined as the default action for an event. You're not calling the EVENT, but the code subroutine set to run when that event occurs.
David-W-Fenton
2009-11-11 02:46:42
All that said, I think it's better coding style to have standalone subroutines with names that indicate what they do and call those from the individual command buttons and from the command button that runs them all. But it's only a matter of organizing your code rationally so that it's easy to read and understand, not something inherent in VBA that makes it undesirable.
David-W-Fenton
2009-11-11 02:48:15
@David: I disagree with your first statement from a semantic standpoint. And in your second statement I would like to clarify that I didn't mean to imply that VBA in itself that makes this undesirable, rather I'd like to press the point that code should follow what you really mean, if you mean that Button1 causes Button2 to be clicked, then calling the Button2.Click event is okay, but if you really mean that Button1.Click and Button2.Click both cause the same logic to occur, then code what you mean. Separating concerns actually simplifies the code and makes it more readable and maintainable.
BenAlabaster
2009-11-11 13:57:06
+1
A:
All you have to do is call the Click event of the buttons inside the Click event of the one single button.
Also command buttons in Access don't have a BackColor property, the work around would be to use third party tools or You can use a picture and use that as the command button's 'picture' property.
Anand
2009-11-10 10:45:12
Yes, it will execute in order. For example if you called Command2_Click followed by Command3_Click , the code in Command2_Click will get executed first and when the control returns back to the calling function it will then call Command3_Click
Anand
2009-11-10 11:12:10
This is a common bad practice. Best practices for a number of reasons are to split the code out from the events themselves so they can be called from other areas of the code. An event on one object shouldn't raise an event on another object.
BenAlabaster
2009-11-10 21:17:18
You shouldn't call events from other events, this is a bad practice and shouldn't be promoted.
BobTheBuilder
2009-11-10 22:52:02
You're not calling events, you're calling the code assigned to events, and there's not difference between calling that and calling any other subroutine. I would agree that it makes more sense when you need to do the same action in two locations to write a single sub for that and then call it in both places, but the comment about calling events from events is gibberish.
David-W-Fenton
2009-11-11 02:43:53
@David: I don't think it's gibberish at all. Calling an event from another event is (in most cases) semantically incorrect. Button1.Click wouldn't (usually) cause Button2 to be clicked, rather it would cause the same logic to be processed had the Button2.Click event occurred. Your code should be structured as you really mean it to be structured. If clicking Button1 *really causes* Button2 to be clicked, then okay, chaining the events is okay, but unless you really mean that, don't do it. It is important that code is semantically correct for readability and future maintainability.
BenAlabaster
2009-11-11 13:51:11
+5
A:
It's good programming practice to not put code inside the event of an object - such as the click event. Instead the code should be put into their own methods which are called by the click event. Then when you need to run a whole bunch of them, you don't need to call the click event of each button, but instead run each of the methods that the click events call directly.
Private Sub DoSomething()
'Code to do something
End Sub
Private Sub DoSomethingElse()
'Code to do something else
End Sub
Private Sub Button1_Click(sender As Object, e As EventArgs)
DoSomething
End Sub
Private Sub Button2_Click(sender As Object, e As EventArgs)
DoSomethingElse
End Sub
Private Sub Button3_Click(sender As Object, e As EventArgs)
DoSomething
DoSomethingElse
End Sub
This also makes for much more testable code... not that code is particularly testable inside of a Microsoft Office application. But that's a commonly used industry best practice.
BenAlabaster
2009-11-10 21:09:33
I would not make it a categorical, though -- don't take the code out of the event until the point at which you need to call it from two places, as in your case.
David-W-Fenton
2009-11-11 02:42:16
@David: I'd argue against that - it is my opinion that logic shouldn't be handled inside event handlers, that's just a path I don't go down any more. It causes more problems than it solves - unit testing (which may not be relevant in this particular example) rapidly becomes a PITA. Chaining of events is misleading because unless you *really mean* that the Button1.Click event causes Button2 to be clicked, then you shouldn't be calling the Button2.Click event - it's misleading and semantically incorrect. What you mean is that the Button3.Click event calls the same logic as Button2.Click.
BenAlabaster
2009-11-11 13:42:34
A:
I also got a way to change the color. though i am not changing the color of the button i am able to change at least the color of the caption on teh button using forecolor option.
tksy
2009-11-12 13:03:41
If you also want to change the background colour, you could use the tips described at http://bytes.com/topic/access/answers/191595-how-change-background-color-buttons
littlegreen
2009-11-12 22:29:19