Solved Report Checkbox On Click Fires Twice (1 Viewer)

[Mike_10]

I can not figure out why the On Click event for a checkbox placed on a report is executing the sub twice. I double checked this in a new database with nothing else except a blank report with the checkbox and it’s still doing this. What’s going on here?

I have a database that I built several months ago that has a report with a couple check boxes on it and it does not exhibit this behavior. Nothing special about the VBA or report design on that one, and works as expected, executing the sub once per click. I’m completely stumped.

 

[theDBguy]

Hi. Are you viewing the report in Report View? Just curious...

 

[Mike_10]

Yes, viewing in report view and clicking the checkbox from there.

 

[Cronk]

I've only ever had a check box on a report to display data. However I did add an unbound check box to a continuous report with a messagebox on the on click event of the checkbox and the message comes up twice per click.

Begs the question as to why you have such a checkbox on a report.

 

[theDBguy]

Yes, viewing in report view and clicking the checkbox from there.

Okay, to understand this, I created a little test. I added a command button to a report, and it only fired once. I then added a checkbox, and it fired twice. I know some code fire multiple times in a report because the whole report has to be evaluated for any dependencies like total pages, but I can't say that is why there is a difference between a command button and a checkbox (maybe).

In any case, what is the purpose of your checkbox? Is it bound to a field in the table? If not, I was just wondering if you can use a button that may look like a checkbox for the same purpose.

 

[Mike_10]

Yes of course I could use a button if this issue is going to remain. Just seems more intuitive to use a check box in this case. I’m giving the user the option to either display or not display a part of the data.

It’s just such a bizarre behavior, I’d love to know what’s causing this.

 

[theDBguy]

Yes of course I could use a button if this issue is going to remain. Just seems more intuitive to use a check box in this case. I’m giving the user the option to either display or not display a part of the data.

It’s just such a bizarre behavior, I’d love to know what’s causing this.

Hi. Like I said earlier, this is normal behavior for some things on a report because a report has to be run at least once, including all event code, before it can be rendered to give you an accurate preview.

I was just not 100% sure if it's the same case for your checkbox (without seeing your report and the code behind it).

 

[arnelgp]

if you will put on the click event of the checkbox:

Debug.Print [checkboxName]

the checkbox will fire 2 times.
first time, the Old value of the checkbox.
next fire, the New value of the checkbox.

 

[Mike_10]

Seems weird to me at least. Why just the checkbox control?

Either way, I figured out a simple workaround. If you execute a requery on the report from inside the checkbox "On Click" event it will only run the sub once. The only part to this is that it will not change the value of the checkbox which means I had to add an IF-THEN-ELSE statement before the requery to find the value and then manually switch it. Maybe not the most elegant solution but seems better than having the sub run twice for no reason.

 

[Minty]

When you click on a checkbox, you are doing two things, clicking on it AND changing its value.

The click event does fire twice uniquely because of this. I'm sure there was another question recently about similar behaviour.

 

[theDBguy]

Seems weird to me at least. Why just the checkbox control?

Either way, I figured out a simple workaround. If you execute a requery on the report from inside the checkbox "On Click" event it will only run the sub once. The only part to this is that it will not change the value of the checkbox which means I had to add an IF-THEN-ELSE statement before the requery to find the value and then manually switch it. Maybe not the most elegant solution but seems better than having the sub run twice for no reason.

Hi. Here's another tidbit I just found out while continuing to experiment with this issue. When I had an unbound Checkbox, clicking on it fired the event twice and changed its value. This is explained by both @arnelgp and @Minty posts. However, when I used a bound Checkbox, the event only fired once (or at least, I only saw the Msgbox show up once) but got a "ding" afterwards where Access complained that the Report was "read only."

 

[Mike_10]

Why would the sub need to fire twice to make the value change (assuming unbound)? Obviously this isn’t necessary with forms. I just can’t wrap my brain around why this is necessary change the value. At least let the programmer write code to make the value change but don’t fire twice.

Would we expect this same behavior with option (radio) buttons? I haven’t tried it.

 

[Isaac]

Why would the sub need to fire twice to make the value change (assuming unbound)? Obviously this isn’t necessary with forms. I just can’t wrap my brain around why this is necessary change the value. At least let the programmer write code to make the value change but don’t fire twice.

Would we expect this same behavior with option (radio) buttons? I haven’t tried it.

Why would you want to use the Click event of a checkbox in the first place? This probably doesn't come up often, because people don't do what you're doing very often.

 

[Mike_10]

Why would you want to use the Click event of a checkbox in the first place? This probably doesn't come up often, because people don't do what you're doing very often.

Why wouldn’t you want to use it? The user clicks the checkbox, and something should happen. Seems obvious (to me at least) to put the instructions in the On Click event sub. Oh and that something that should happen, shouldn’t happen twice unless the programmer tells it to.

Even if it’s poor programming practice to use this event, seems like a glitch.

Is there anywhere else in Access where an on event executes twice even if the event only happens once?

 

[Isaac]

Why wouldn’t you want to use it? The user clicks the checkbox, and something should happen. Seems obvious (to me at least) to put the instructions in the On Click event sub. Oh and that something that should happen, shouldn’t happen twice unless the programmer tells it to.

Even if it’s poor programming practice to use this event, seems like a glitch.

Is there anywhere else in Access where an on event executes twice even if the event only happens once?

Sorry, but this is where you've gone wrong. People don't use the Click event - they use the AfterUpdate event, same as a combobox or listbox.

PS - I agree about the glitch, just saying it doesn't come up because people don't use the Click event of the cbo, lb, or cb very often.

 

[Mike_10]

Sorry, but this is where you've gone wrong. People don't use the Click event - they use the AfterUpdate event, same as a combobox or listbox.

PS - I agree about the glitch, just saying it doesn't come up because people don't use the Click event of the cbo, lb, or cb very often.

I'm surprised people don't use the On Click event for a checkbox. Obviously I have no formal training in this so I've been doing it. There is not an AfterUpdate event for a checkbox so that's why I was using the On Click event.

What do most people do instead? Let's say we want to display or hide (basically filter) certain report records depending on the user's selection. What's the most concise and elegant way to design and code this? And what's the most intuitive interface for user experience?

 

[Minty]

There is not an AfterUpdate event for a checkbox so that's why I was using the On Click event.

Yes there is :

And that's what I would use, this is unbound control in a form.
I'm not sure there would be an after update event in a Report as it's not and can't be attached to live data.

 

[gemma-the-husky]

Maybe it's because the checkbox is printable. I think a report processes twice, once to arrange the pagination, and secondly to do the print. It has to do that. It can't evaluate percentages, give page summaries (1 of x) , and so on, unless it knows the report totals.

I'm sure I had reports where a calculation within the report went wrong, because it calculated for the preview, and then for the print. Maybe you need to be careful with report interactions.

 

[Mike_10]

Yes there is :
View attachment 88632
And that's what I would use, this is unbound control in a form.
I'm not sure there would be an after update event in a Report as it's not and can't be attached to live data.

That's only for a form. I'm only talking about reports because that's the only place that exhibits this behavior. There is not an After Update event for a checkbox on reports.

 

[Mike_10]

Maybe it's because the checkbox is printable. I think a report processes twice, once to arrange the pagination, and secondly to do the print. It has to do that. It can't evaluate percentages, give page summaries (1 of x) , and so on, unless it knows the report totals.

I'm sure I had reports where a calculation within the report went wrong, because it calculated for the preview, and then for the print. Maybe you need to be careful with report interactions.

Yes, lesson learned that this is something to be careful with. Just seems like if a checkbox On Click event on a report is an option that is not supposed to be used then it wouldn't be designed into the software to begin with.

If Assumptions![Checkbox On Click].[Can Be Used On Reports] = True Then
Debug.Print "We fooled you!"
Else
Debug.Print "You obviously know what you're doing."
End If