VBA: how to handle hyperlink subaddress

[Edward Thrashcort]

Why does MS have to make things SO awkward!!

I am trying to parse an internet address from a Word Hyperlink with VBA

Let's say the address is "index.htm#inlineanchor"

No problem

With Selection.Hyperlinks(1)
URL = .Address + "#" + .SubAddress
End With

However, if there isn't a sub-address, the hyperlink object doesn't return a
blank or even a null. Oh no! It returns an error that the subaddress is
not defined!!!!!!

How can I handle this to determine if a subaddress has been defined?


Eddie

 

[Edward Thrashcort]

OK I'll answer my own question BUT let me say I think relying on Error
states is BAD programming technique.

Dim sSub, URL
sSub = ""
On Error Resume Next
With Selection.Hyperlinks(1)
URL = .Address
sSub = .SubAddress
If sSub <> "" then URL = URL + "#" + sSub
End With
On Error Goto 0

Eddie

 

[Jonathan West]

OK I'll answer my own question BUT let me say I think relying on Error
states is BAD programming technique.

Not at all. Errors (more properly called exception conditions) are a valid
means of signalling to a calling routine that an event has occurred in the
called routine. Using On Error Resume Next as you have done is a perfectly
good way of responding to an *expected* error condition in a simple case
such as you have described below.

People get hung up on the word "error", and think they are bad. Get over
that, and accept that error conditions are created deliberately and for a
purpose, and that error handling is a valid programming technique.

In VBA, the problem is further compounded by the fact that Goto is the only
thing you can do with an error apart from Resume, and too many people have
bought into the prejudice that GoTo is the spawn of the devil and no use of
it should ever be made in a structured program. Certainly it is possible to
create spaghetti code by overuse of GoTo, but it is a useful construct in
appropriate circumstances.

Dim sSub, URL
sSub = ""
On Error Resume Next
With Selection.Hyperlinks(1)
URL = .Address
sSub = .SubAddress
If sSub <> "" then URL = URL + "#" + sSub
End With
On Error Goto 0

What is bad programming technique in the code sample above is declaring sSub
and URL as Variant rather than as String, and using + for string
concatenation instead of &. I'm not overly keen on using single-line If-Then
statements either. The code is usually more readable if you separate it out
and indent. Properly done, the code would look like this

Dim sSub As String
Dim URL As String

sSub = ""
On Error Resume Next
With Selection.Hyperlinks(1)
URL = .Address
sSub = .SubAddress
If sSub <> "" Then
URL = URL & "#" & sSub
End If
End With
On Error Goto 0

 

[Edward Thrashcort]

Thanks for the comments Jon

Incidentally, what is "wrong" with

string1 + string 2

compared to

string1 & string 2

Eddie

 

[Russ]

The help for '&' says that the ampersand forces a string result
to get rid of the ambiguity of the '+' character usage, which is normally
associated with numeric results.

 

[Jonathan West]

Thanks for the comments Jon

Incidentally, what is "wrong" with

string1 + string 2

compared to

string1 & string 2

The & operator is a string concatenator in all circumstances, forcing
conversion to strings as necessary. The + operator does concatenation if
everything is a string, and addition otherwise.

If you're *absolutely* sure that string1 and string2 are both strings, then
your are OK. But you declared them as variants

Try this little program

Dim string1, string2
string1 = "123"
string2 = "456"
Debug.Print string1 + string2, string1 & string2
string1 = 123
Debug.Print string1 + string2, string1 & string2

Now, in the little example above, it is clear than string1 was numeric in
the second calculation. But if the variable is being assigned from something
else, that is not going to be nearly so obvious. Much better to use & if you
definitely want to concatenate strings.

In older versions of VB, up to VB3, you couldn't do this at all - you had to
explicitly convert strings and numbers using functions like Val and Str$.
The variant datatype and this automatic coercion of data types was
introduced in VB4. It caused such confusion that it was rapidly nicknamed
Evil Type Coercion, or ETC for short.

The rules for how the automatic coercion works are not well-documented,
although they are consistent. But finding a bug in a program where you are
relying on the behavior of ETC and you have a wrong datatype can be
difficult and frustrating. It is much better for debugging and maintenance
purposes to avoid the variant datatype except for specific cases where
nothing else will do (e.g. using one to hold an array and assigning the
while array in one command, e.g. to the list property of a ComboBox), to
explicitly convert where necessary, and to use & for concatenation. That
way, you have control over how expressions are built, and you don't rely on
the default behavior of ETC.