Using document properties

[Lighthouse]

I have a template that includes an autoopen macro that prompts the user
to perform a certain manual action. This action is only required the
first time the document is opened. After that, the prompt is annoying.

I *think* what I want to do is have my autoopen check for the existence
of a document property, and if it exists, it should terminate the
autoopen macro. if the property does not exist it should add it and
continue w/ the macro (issuing the prompt).

The document property should be transparent to the casual document
user.

I'm looking for some advice if this is the best way to do this and how
it should be coded. I'm at the 'danger to myself' level of proficiency
w/ VBA. TIA

 

[Greg Maxey]

What happens if you put your prompt in an autonew vice autoopen macro?

 

[Lighthouse]

I don't think that would work. my word document is generated from a 3rd
party app, using my word template. the first time it's opened by a
human it's no longer "new"--it already has a name.

 

[Greg Maxey]

This may not be the cleanest method, but you could use something like:

Sub AutoOpen()
On Error GoTo CreateVar
If ActiveDocument.Variables("Flag").Value = "Set" Then
Exit Sub
End If
Finish:
MsgBox "Your Prompt"
Exit Sub
CreateVar:
ActiveDocument.Variables("Flag").Value = "Set"
Resume Finish
End Sub

 

[Lighthouse]

That's exactly what I needed. Works like a charm. Thanks!

 

[Chuck]

Forgive my adding 2 cents worth...

Greg's solution using document variables is preferable (IMHO) to using
document properties because document variables are available to VBA for
adding/changing/deleting regardless of whether the document has been
protected for forms or not. Document properties on the other hand can be
unavailable if the document has been protected for forms unless the user (or
the macro) provides the relevant password. (At least in Word 2000)

Document properties have their place but in situations where documents *may*
be protected by users, document properties could be more suitable. The
downside to document variables is that they can't be edited/changed/deteled
except through code whereas document properties can be edited by users via
File>Properties.

I've run into problems with this issue, where a developer decided to use
document properties for important interoperability settings, but users need
to password protect documents on a regular basis, causing the program to fail.

 

[Greg Maxey]

Chuck,

The reason I highlighted that the method I suggested may not be the cleanest
is because it intentionally causes a run-time error. It seems like I saw a
method once for doing something like this that doesn't require creating an
intentional run-time error but I don't remember how it was done.

 

[Jonathan West]

Chuck,

The reason I highlighted that the method I suggested may not be the
cleanest is because it intentionally causes a run-time error. It seems
like I saw a method once for doing something like this that doesn't
require creating an intentional run-time error but I don't remember how it
was done.

Don't worry about creating runtime errors and using error-handling code to
trap them. In fact "Error" is a rather unhelpful name, and implies that you
have done something wrong. Instead, think of it as an "exception". Your
error-handling code deals with a defined and known condition (in this case,
that the document variable doesn't exist). Think of it as just another
branching and program control mechanism.


--
Regards
Jonathan West - Word MVP
www.intelligentdocuments.co.uk
Please reply to the newsgroup
Keep your VBA code safe, sign the ClassicVB petition www.classicvb.org

 

[Chuck]

I'm feeling a bit dim today. Where/what is the intentional run-time error?

 

[Jean-Guy Marcil]

Chuck was telling us:
Chuck nous racontait que :

I'm feeling a bit dim today. Where/what is the intentional run-time
error?

If ActiveDocument.Variables("Flag").Value = "Set" Then

will generate an error if the variable does not exist. Greg is using that as
a test.

--
Salut!
_______________________________________
Jean-Guy Marcil - Word MVP
(e-mail address removed)
Word MVP site: http://www.word.mvps.org

 

[Chuck]

Ah. I always check whether the variable exists before doing anything with it
- it's extra code but more controlled than triggering errors - something like:

blnFound = False

For Each docVar in ActiveDocument.Variables
If docVar.Name = "X" Then
blnFound = True
Exit For
End If
next docVar

If blnFound = True Then
'do something
End If

 

[Greg]

Chuck,

I considered this method. It works of course, but then seems awkward
if the document contains lots of variables. It may be that this is the
method that I saw before that didn't generate the error, but I can't
remember.

 

[Chuck]

I suppose it would impose a slight performance overhead, but only a matter of
milliseconds even with hundreds of variables because it's only checking the
names not doing any processing on each variable...

 

[Greg Maxey]

Jonathan,

Thanks for your endorsement on a method that I felt certain would be frowned
upon by more experienced people.

 

[Chuck]

Hi Jonathan

The problem with relying on run-time errors as a decision making process
(IMHO) is that you have to be absolutely sure that the only error that could
possibly be created by your code is exactly the one you want to trap for. In
my experience that's rarely the case -- I've had to spend a lot of time
debugging code that relied erroneously on error handling to do its condition
testing because while the code worked in the rarified atmospher of the
developer's cubicle in specific test conditions, it choked when confronted
with the mess of the real world. It may seem like a shortcut but - again in
my experience - it can lead to unforeseen time and effort wastage later on.

A little like shortcutting with "If blnSomething Then" instead of "If
blnSomething = True Then" - as pointed out in a recent thread the first
doesn't actually test for True but instead for "not False" which is a
potential problem if you really want to know whether the variable is True or
False.

Another thing is that (it seems to me) if you do rely on error handling as a
condition testing mechanism then you have to make sure your code contains a
number of "On Error" statements along with appropriate routines which can end
up being the same or more amount of coding than just coding the condition
testing correctly in the first place. That's not a problem in Greg's code of
course because it's a self-contained situation but if (for example) it were
part of a longer sub it would need to be followed by another "On Error"
statement trapping for different or general errors so that subsequent errors
didn't get directed to the Finish routine, no?

Sorry but this is a bit of a bugbear with me. Greg's code is specific and
seems fine, it's more the general principle that I'm talking about.

Then again, maybe I'm wrong!

Chuck

 

[Jonathan West]

Hi Chuck,

There are various answers to your primary concern, i.e. that error-handling
code is unnecessarily general, and may end up processing an unexpected
error.

1. You can have cases such as Greg's code example, where only one error is
really possible, and it is trapped and appropriately processed. Like you, I
see no problem with such cases.

2. Where the range of possible errors is wider, the error handling code can
itself branch according to the error raised (e.g. by checking the value of
the Err.Number property). Alternatively, you can have different error
handlers for different parts of a routine, by having different On Error Goto
statements at different points in the code.

3. Suffering *unexpected* errors is down to bad design and/or inadequate
testing, There no difference in principle between having such unexpected
errors cause a program to stop because they are unhandled, or causing a
program to behave in an unplanned way because the error handler is
inappropriate. In disapproving of error handling as a programming technique
because of such circumstances, I think you are taking aim at the wrong
target. The thing you should be objecting to is the bad design &/or
inadequate testing that leads to unexpected errors occuring.

Error handling code is all to do with addressing *expected* exception
conditions. It may be that in some circumstances it is more efficient to
avoid raising the error by finding an alternative test of the condition and
branching to another part of code. But error handling of expected and
deliberately raised exceptions is a perfectly valid programming technique.

Unfortunately, in VBA the only error-handling syntax available is an
unstructured Goto. Thus, error handling in VBA has got caught up in the
"using Goto is inherently evil" debate. Other languages have a richer more
structured error-handling syntax, and so error handling in those languages
is not regarded as being so morally questionable.

--
Regards
Jonathan West - Word MVP
www.intelligentdocuments.co.uk
Please reply to the newsgroup
Keep your VBA code safe, sign the ClassicVB petition www.classicvb.org

 

[Chuck]

Hi Jonathan

Thanks for the clarification and points taken. I suppose at the end of the
day, as long as the code is well-thought out, easily managed by subsequent
coders and does the job, then it comes down to coder's preference.

Chuck

 

[Jonathan West]

Hi Jonathan

Thanks for the clarification and points taken. I suppose at the end of
the
day, as long as the code is well-thought out, easily managed by subsequent
coders and does the job, then it comes down to coder's preference.

Chuck

Exactly so!

Code I post here is available for everyone to see and comment on - adversely
if appropriate! Because of this, I always try to ensure that each code
sample is something close to an optimal approach to a problem. The
discipline of that has done wonders for the efficiency of coding style. I
never have any problem with somebody suggesting an alternative approach, or
with somebody asking why the approach I use is better than some alternative.
After all, they might be right, in which case I can improve my own style! I
can see that Greg's code is improving in the same way.

Within the constraint of getting a fairly optimal approach, I regard
"coder's preference" as being a matter of maintaining a *consistent* style,
since consistency makes code easier to read and understand, and therefore
easier to maintain and update.


--
Regards
Jonathan West - Word MVP
www.intelligentdocuments.co.uk
Please reply to the newsgroup
Keep your VBA code safe, sign the ClassicVB petition www.classicvb.org