how do u define a variable to store decimal values (W97 – sr2)

Topic

New Reply

Hi all

I want a variable to store decimal values eg
2.73
-0.04

however when I define the variable as long or as integer & I set the variable
the values are not stored.
the variable result is either
the next rounded number eg 2.73 to 3
or just contains 1.

can someone please let me know how I should define my variable?
many thanks Diana

can

Reply | Quote

Replies

Hi Diana

Do they really need to be stored as long or integer values?

What about a simple string? Are you using the values in calculations that absolutely require numbers?

Leigh

Reply | Quote

HI Leigh

the variable can be defined as anything.
I’m not using the values for calculations.
The values are used to format & align objects in word.

Diana

Reply | Quote

You can’t store decimals in a long or integer because by definition those datatypes hold whole numbers. If you want to store decimals, use a single or a double or even a currency type.

Reply | Quote

Hi Diana,

Charlotte’s advice is on the money.
Specifically, for things like indents and alignments in Word, you want to use the Single data type.

Gary

Reply | Quote

I must admit I often use the Variant data type in such cases (that is, I simply use “Dim myIndent” without any type).
Then I let Word worry about the type cast, if any is necessary.

Dim myIndent
myIndent = 8.5
...
Selection.ParagraphFormat.LeftIndent = myIndent

Some may call this sloppy programming, but I’m lazy…

Klaus

Reply | Quote

An example where the type of the parameter is hard to predict:

Selection.ParagraphFormat.LeftIndent
(in pt) is defined as “Single”,
Selection.ParagraphFormat.Borders.DistanceFromLeft
(in pt) is defined as “Long”.

Klaus

Reply | Quote

Not necessarily sloppy, but definitely inefficient. The variant datatype takes the most resources without returning anything but flexibility. Since you have a pretty good idea of the datatype you need for things like indents, it makes sense to use the appropriate datatype in your code.

Reply | Quote

Not only inefficient, ir exposes you to the “evil of type coercion” problem as VB/VBA has a mind of its own and may convert types at inappropriate times.

Reply | Quote

I’d make a different point about efficiency, and that has to do with reuse and sharing of your code. It’s much easier to reuse and share code that uses a variable naming convention, and using a variable naming convention goes hand in hand with declaring types.

Some of the code posted here would be much easier to following if the variable data type were more obvious from the name.

As far as internal efficiency and Howard’s comments about the dangers lurking behind type coercion, it seems we’re not going to have much choice in the matter, once VB.Net makes its way over to Office. If I understand it right, variable typing there works like it does in VB Script – variable type declaration isn’t supported and everything is a subtype of Variant, the subtyping presumably done by the kind of coercion Howard’s referring to.

Seems sort of the worst of both worlds since the variable isn’t explicitly typed, but you’d still have to determine the variant subtype and code accordingly (as if it were typed), in many cases (I’d guess….)

Maybe someone here who’s worked with VB Script could share some views on the pros and cons of untyped variables?

Gary

Reply | Quote

I haven’t worked with .Net, but my understanding was that it required explicit typing and didn’t allow variants at all.

Reply | Quote

VB.net does have all of the VB data types, except there is no longer a Variant data type.

In VB.net, all data types are a special case of the Object data type, but you can still type variables as String, Long, etc.

In addition, VB.net adds a new statement Option Strict.
If Option Strict is On, then the code has to do all type conversions explicitly with, say, cast functions. If Option Strict is Off, then I believe the evil of type coercion can occur.

Reply | Quote

Howard,

Thanks for the info.

It’s unusual that MS have done so much to discourage explicit typing in the past- and have suddenly forced it. Any example from Help from MS product have not typed variables. Here’s a memory jog for examples of wehat I mean.

If MS had been really serious about typing, the help would have been giving examples many years ago. Instead, the help has encouraged people to be loose.

I suspect with .Net, it’s just too hard to allow variant data types- so they just said “it’s sloppy programming” and pulled the plug on it.

Reply | Quote

Hi Charlotte,

[indent]

---

Since you have a pretty good idea of the datatype you need for things like indents, it makes sense to use the appropriate datatype in your code.

---

[/indent]
As my example showed, having a pretty good idea isn’t enough, you have to look up the type of every parameter in the documentation.
If you’d define .ParagraphFormat.Borders.DistanceFromLeft as Single, you might be in for a surprise when you use a non-integer value like 8.5

I knew I would be in for a bashing with this post, so I want to emphasize I do use type declarations for all objects in the Word Object Model, and for most other variables like strings, integers …

Klaus

Reply | Quote

Most all of the numeric properties in Word, especially the numeric properties of the ParagraphFormat object are single, so you should define them as single, for example:

Option Explicit
Sub Macro1()
Dim sngIndent As Single
    sngIndent = Selection.ParagraphFormat.RightIndent
    Selection.ParagraphFormat.LeftIndent = 1.5 * sngIndent
End Sub

When in doubt, the help file for a property usually tells you the data type. HTH –Sam

Reply | Quote