Command Button (1 Viewer)

[kitty77]

What is the vba code for: afterupdate, goto a command button and click it?

 

[theDBguy]

Just call the click event. For example:

ButtonName_Click

 

[kitty77]

When I click the button manually, it works. It opens another form. When I use Command5_Click I get an error.

 

[kitty77]

 

[theDBguy]

When I click the button manually, it works. It opens another form. When I use Command5_Click I get an error.

Can you show us the code in the Click event of the button please? Thanks.

 

[The_Doc_Man]

Since there is no parameter inherent in a Click event try this:

Call Command5_Click

Then put a breakpoint on that line of code. When it breaks, single-step (using Step-Into, which you can find on the VBA code-page menu). One line at a time see what it does.

 

[Uncle Gizmo]

Just call the click event.

Not considered good practice.

It's better it you put the command button code in its own routine and call that from the command button and elsewhere....

 

[kitty77]

Here is what's in the command button.

 

[theDBguy]

Here is what's in the command button.
View attachment 98482

Ah, that's an embedded macro. Not sure you can execute it another way aside from clicking on the button. If you must use macros, you might use a named macro instead. Otherwise, you could repeat/duplicate the macro in your other code. Just a thought...

 

[kitty77]

Yes, that did it. Thanks!

 

[theDBguy]

Yes, that did it. Thanks!

Hi. Glad to hear you got it sorted out. Good luck with your project.

 

[isladogs]

Not considered good practice.

It's better it you put the command button code in its own routine and call that from the command button and elsewhere....

Why?

 

[Pat Hartman]

I think it probably depends on which event you want to call whether or not it is dangerous. I also tend to make procedures when I want to reuse code just for neatness and to make it clear that the code is being reused.

 

[Uncle Gizmo]

Why?

It surprises me how many times I see this done. I was taught it was bad practice in my early days of MS Access programming, by my mentors. I didn't rightly know why at the time, but as you start to develop more sophisticated code you start to see the sense in it.

If the code is only applicable to the command button, then leave it there. If you need to call it from elsewhere, then you should refactor it into its own method.

Code called from more than one place should not be tied to a particular control. If you rename your command button, the code that is calling the command button event handler will fail.

If you update the code within the command button event handler, you might not be aware that it is being called from elsewhere and introduce a bug.

It's better coding style to have a standalone procedure with a name that indicates what it does.

It's a more elegant solution and is much easier to maintain.

It makes it easy to reuse the code when it is separate from the command button event handler. It is also easier to test and maintain.

 

[theDBguy]

Given that the OP posted the code behind the button in question, does anybody still think it belongs in a Standard Module? Just curious...

 

[Uncle Gizmo]

does anybody still think it belongs in a Standard Module? Just curious...

Ha! Its a macro!

It should immediately be converted into VBA and the perpetrator of the offence should be banned from (AWF) Access World Forums!

 

[Uncle Gizmo]

It should immediately be converted into VBA

The following YouTube video shows you how to convert a Macro into VBA.

 

[theDBguy]

Ha! Its a macro!

It should immediately be converted into VBA and the perpetrator of the offence should be banned from (AWF) Access World Forums!

But I was referring to its content (the code inside the macro). Even if you convert it into VBA, do you really think it should be in a Standard Module. I was just curious...

 

[isladogs]

I totally agree that code repeated more than once should be transferred to a separate procedure, either within the form module or, where appropriate, in a standard module. I do that all the time for exactly the reasons Tony described.

However, in this case where the button click code is simple and used in just one other place, I see no reason to create a separate procedure just for the sake of it. However, I would definitely replace that embedded macro with VBA

 

[Uncle Gizmo]

If the code is only applicable to the command button, then leave it there.

where the button click code is simple and used in just one other place, I see no reason to create a separate procedure just for the sake of it

Yes, as I said....