Converting and Integer to String in VBA

[VexedFist]

I have a MACRO I wrote in MS-Word 2003.

I am trying to figure out how to convert an Integer iNum to a Strin sNum.

Any help would be appreciated

 

[macropod]

Sub Test()
Dim iNum As Integer
Dim sNum As String
iNum = 50
sNum = iNum
MsgBox sNum
End Sub

Cheers

 

[Karl E. Peterson]

Hi,

Typical functions are str...

CStr is really a better recommend, especially to someone who needs to ask a question
like this (ie, a total newb), than Str. Why? Because they won't have to come back
and ask about the leading space from Str. Being a self-proclaimed oldman (as am I),
I know where you're coming from. This generation never will.

 

[old man]

Who am I to argue with MVPs? Cstr is usually better since you a trimmed
string. Macropd is correct that there are automatic conversions but people
who depend on automatic conversions are like people who drive without seat
belts - one day they may regret it.

old man

Sub Test()
Dim iNum As Integer
Dim sNum As String
iNum = 50
sNum = iNum
MsgBox sNum
End Sub

Cheers
--
macropod
[MVP - Microsoft Word]
-------------------------

I have a MACRO I wrote in MS-Word 2003.

I am trying to figure out how to convert an Integer iNum to a Strin sNum.

Any help would be appreciated

 

[Karl E. Peterson]

Who am I to argue with MVPs? Cstr is usually better since you a trimmed
string. Macropd is correct that there are automatic conversions but people
who depend on automatic conversions are like people who drive without seat
belts - one day they may regret it.

Google "coercion aversion" sometime <g> to find a case where:

A + B + 1 <> 1 + A + B

(Despite the ugly typo in the subhead.)

When VB5 entered a pre-alpha state, given the debacle of VB4's ETC, we were
*strongly* arguing for an Option Anal or Option ExplicitDamnItForReal to force all
coercions be explicit. Unfortuantely, they didn't see the wisdom in that. :-(

 

[old man]

well you can set explicit conversions required in vb.net

old man

 

[Karl E. Peterson]

well you can set explicit conversions required in vb.net

Yeah, unfortunately, you can't use your VB code there. :-(

 

[macropod]

True, a purist might use something like:
Sub Test()
Dim iNum As Integer
Dim sNum As String
iNum = 50
sNum =cStr( iNum)
MsgBox sNum
End Sub

As for automatic conversions, I've heard much the same line about automatic transmissions in cars...

Cheers
--
macropod
[MVP - Microsoft Word]
-------------------------

Who am I to argue with MVPs? Cstr is usually better since you a trimmed
string. Macropd is correct that there are automatic conversions but people
who depend on automatic conversions are like people who drive without seat
belts - one day they may regret it.

old man

Sub Test()
Dim iNum As Integer
Dim sNum As String
iNum = 50
sNum = iNum
MsgBox sNum
End Sub

Cheers
--
macropod
[MVP - Microsoft Word]
-------------------------

I have a MACRO I wrote in MS-Word 2003.

I am trying to figure out how to convert an Integer iNum to a Strin sNum.

Any help would be appreciated

 

[Karl E. Peterson]

True, a purist might use something like:

That's belittling.

Sub Test()
Dim iNum As Integer
Dim sNum As String
iNum = 50
sNum =cStr( iNum)
MsgBox sNum
End Sub

Maybe you're a newb, in which case such arrogance is understandable, but it wasn't
until VB4's introduction of Evil Type Coercion that such an assignment would fail to
generate a "Type Mismatch" error. Survivors in the crowd know better than to trust
default behaviors.

As for automatic conversions, I've heard much the same line about automatic
transmissions in cars...

I was listening to Car Talk on NPR a few weeks ago, and some poor slob called in
with a sob story that's perhaps appropos. Seems he'd bought a "4-speed" car (forget
what make/model) a few years ago, and had driven it happily all this time. Well, lo
and behold, turns out now that it's actually a 5-speed tranny, and the last owner
had apparently swapped gear knobs (to one that only diagrammed 4 gears, rather than
all 5) at some point. Oh how silly this guy felt. Shoulda heard the Tappet
brothers laugh. Hell, I even felt sorry for the guy.

 

[macropod]

Hi Karl,

It wasn't meant to be belittling, but I can't see how using the automatic type conversion tools built into vba in any riskier than
doing it manually - regardless of what happened with an app (vb3) that was superseded over a decade ago.

If there is a material risk doing this in vba, please say what it is. AFAIK, all vba implementations support it.

Regards

 

[Karl E. Peterson]

It wasn't meant to be belittling, but I can't see how using the automatic type
conversion tools built into vba in any riskier than doing it manually -
regardless of what happened with an app (vb3) that was superseded over a decade
ago.
If there is a material risk doing this in vba, please say what it is. AFAIK, all
vba implementations support it.

As we found in the VB3/VB4 transition days, the real risk was in trusting default
behaviors to remain consistent through time. As things stand, ClassicVB is now
probably *the* most stable language on the planet, eh? <g> But that doesn't mean
VBA isn't subject to some "cleaning up" in the future. The bottom line is, if you
don't depend on default behaviors (automatic coercions, default properties, and so
on), your code can't change behavior in future versions just because some young pup
at MSFT (probably sitting on a copy of Code Complete, so he can reach the keyboard)
decides that VBA could be cooler if only [fill-in-the-blank]. Is it a material
risk? Considering the history (see my sig), it's only immaterial if you consider
your code to be disposable.