Checkbox Macro Help

[Karin]

I want to have 3-4 checkboxes at top of document. If checkbox Apple (for
example) is checked, I want to run a macro that fills in fields in a table.
(I've written the macro) The problem is I need to be able to undo the macro
if they click it again (turning it off). Right now, it runs the same macro
again when it's clicked again. Any guidance would be appreciated.

 

[Scott M.]

In the macro code that responds to the checkbox being clicked, simply check
the checkbox's "checked" property to see if the checkbox is indeed checked
before you modify anything and if it isn't remove the data from the areas
you want cleaned up.

-Scott

 

[Doug Robbins - Word MVP]

Your macro should check for the status of the checkbox

If ActiveDocument.FormFields("Check1").CheckBox.Value = True then
'Code to populate the table
Else
'Code to remove data from the table
End If

--
Hope this helps.

Please reply to the newsgroup unless you wish to avail yourself of my
services on a paid consulting basis.

Doug Robbins - Word MVP, originally posted via msnews.microsoft.com

 

[Scott M.]

FYI: No need to check for true explicitly in an "If" statement as the
compiler always checks for the "truthiness" of your expression.


If ActiveDocument.FormFields("Check1").CheckBox.Value then
'Code to populate the table
Else
'Code to remove data from the table
End If

-Scott

 

[Gordon Bentley-Mix on news.microsoft.com]

Please note that I'm not being critical of your method or looking to pick a
fight; it does work and is generally safe enough. I'm only sharing what I
consider to be a "best practice". What follows is purely my _opinion_ and not
intended to be the "right" or "best" or "only" way to do things.

While this is technically correct, it borders on "sloppy" coding IMHO. I
always prefer to explicitly state the value that I'm checking for. I do this
to ensure clarity and as a visual reminder of exactly what the code is meant
to do - very useful when reviewing code that was written some time ago (which
in my case can be as little as 5 minutes ;-D). This habit also stops me from
doing something stupid like not including the value to evaluate when working
with something like a TextBox - 'cause I know if I get in the habit of
omitting the value for CheckBoxes or OptionButtons, there's a real risk that
I'll start doing it elsewhere. And then there's the matter of 'TripleState'
CheckBoxes and OptionButtons to consider - not a problem with Forms controls,
but ActiveX and VBA UserForm controls do support it. I'm not sure what the
compiler returns if one of these is in its "third state"...

I even extend this practice to things like Boolean functions like IsNumeric.
I always evaluate the value returned from these functions explicitly; e.g.:

If IsNumeric(myValue) = True Then

And I try to avoid using something like:

If Not IsNumeric(myValue) Then

Instead I always use:

If IsNumeric(myValue) = False Then

The reason I consider explicit specification like this to be a best practice
is because I *never* trust the compiler to do something if I can find a way
to do it myself. For example, it's possible to use something like:

myValue = txtMyTextBox

and get the value of a TextBox because .Value is the default property of
TextBoxes. But if for some reason the default property is changed in a later
version of VBA (highly unlike I know but still...), this code will break for
no clearly obvious reason and will have to be revised. However, if you
specify the .Value property explicitly, you're safe.

Just my 2-cents' worth. You're free to do what you like; I'm not going to
call the "VBA cops" on you. <g>
--
Cheers!

Gordon Bentley-Mix
Word MVP

Please post all follow-ups to the newsgroup.

Read the original version of this post in the Office Discussion Groups - no
membership required!

 

[Graham Mayor]

You think so? Try this.

Create a check box and a text form field - leave their default names.
Run the following macro with the box checked

If ActiveDocument.FormFields("Check1").CheckBox.Value = True Then
ActiveDocument.FormFields("Text1").Result = "YES"
End If

Now run it again with the box unchecked.

--
<>>< ><<> ><<> <>>< ><<> <>>< <>><<>
Graham Mayor - Word MVP

My web site www.gmayor.com

<>>< ><<> ><<> <>>< ><<> <>>< <>><<>

 

[Scott M.]

I certainly understand your reasoning, but I don't share it, nor is it
considered a best practice in many circles. There's nothing wrong with it,
but in most cases, it's just asking for the cpu to do redundant work and
therefore it means writing code that is also redundant.

-Scott


"Gordon Bentley-Mix on news.microsoft.com"

 

[Scott M.]

A few things....

1. Your code below is based on using the "MS Forms" controls, rather than
the ActiveX controls that superceded them about 15 years ago.
2. Nonetheless, when I create an MS Forms textbox and checkbox as you
indicated, your code works perfectly fine as expected, so I don't know what
problem you thought would be created, but none was. The code also works
identically when the "=True" portion is omitted as I indicated.
3. If you use the modern ActiveX set of controls, the need to access them
via the more antiquated "ActiveDocument.FormFields("controlName")" paradigm
becomes irrelevant, you simply access the control via it's name, and can
immediately access its properties. For example:

If CheckBox1.Value Then
TextBox1.Text = "YES"
Else
TextBox1.Text = "NO"
End If

Ultimately, I fail to see whatever point you were trying to make. It is
true now and has always been true (in any language) that a compiler will
evaluate an "If" statement to see if its test expression is equal to the
Boolean 'True". So, when evaluating an expression that returns a Boolean
anyway, the extra check for True is simply redundant.

It's no different than writing:

If x = 7 = True then ... (which works, but no one would ever write)

vs.

If x = 7 Then ... (the compiler checkes to see if the results of the
expression is True without having to be told that this is what to look for)

-Scott

 

[Graham Mayor]

While I disagree with your apparent dismissal of MS Forms controls which are
still widely used in preference to ActiveX controls, the point I was trying
to make was based on a misreading of the point that you were making, where
the value is false. My error!

--
<>>< ><<> ><<> <>>< ><<> <>>< <>><<>
Graham Mayor - Word MVP

My web site www.gmayor.com

<>>< ><<> ><<> <>>< ><<> <>>< <>><<>