Help With Data-type Declaration Symbols

[tux792]

It has been many years since using the "$" for typing string variables and "%" for typing integer veriables and such. Now I have forgotten the rest! Does anyone remember the type casting symbols for "char", "double", etc?

Example: ThisIsMyString$ or x$ or x% or BitBucket%, etc. I am programming in VBA for MS Excel and I am trying to Dim variables without having to write " as string" or As Integer". Excel accepts the typing dsignator symbols but I cannot locate a single reference for them.

Thanks,
Jim

[Jackrabbit]

Hi Jim,

You should always use the "Dim VarName As Type" format in VBA. If you don't declare a type, the variables will default to the Variant type (which can hold any type of data but is not very efficient.

Also, according to one book that I have (Excel 2000 VBA, John Green), you should limit variable names to A..Z, a..z, 0..9, and the underscore. In other words, don't use the old style naming conventions.

HTH

[tux792]

Thank you for the response Jackrabbit. Excel accepts the "%" type designator as "Short Integer", the "&" as "Integer", and the "$" type designator as "String". I have verified typing user variables with these symbols as acceptable to the VBA compiler. Using the "!" will set a variable to "FLOAT" with two decimal places and the "@" will type a variable as "Float" with four decimal places; I have not bothered with determining the full ranges of the "!" and "@".

I am fully aware of the vbVariant aspect of VBA programming. It is a memory hog and slows executions measurably. What you have offered about suggested naming conventions for user variables is interesting. Could you please expand a little, with an example or two, along with the specific rational behind this "recomended" convention?

As far as typing variables, DIM AS is the fail-safe, and recomended, method. I just find it more expediant to do a single line DIM than multiple lines with more typing.

This: DIM i%, x%, z&, name$

is much faster (for me) than:
DIM i AS Short, x As Short, z AS Integer, name As String

I looks like VBA does not accomodate the "Char" type variable and, thus far, I have been unable to find any substitute typing symbol for "Byte" (the vbByte variable type). When my counters will not exceed the "-128 to 127" value limits, I always type them as "Byte" to save memory and enhance execution speed.

Thanks,
Tux792

Hi Jim,

You should always use the "Dim VarName As Type" format in VBA. If you don't declare a type, the variables will default to the Variant type (which can hold any type of data but is not very efficient.

Also, according to one book that I have (Excel 2000 VBA, John Green), you should limit variable names to A..Z, a..z, 0..9, and the underscore. In other words, don't use the old style naming conventions.

HTH

[Jackrabbit]

I did verify your findings:

Public Sub VarTest()
   Dim i%, x!, z&, name$

   Debug.Print "i% is type " & TypeName(i%)
   Debug.Print "x! is type " & TypeName(x!)
   Debug.Print "z& is type " & TypeName(z&)
   Debug.Print "name$ is type " & TypeName(name$)
End Sub

Output:

i% is type Integer
x! is type Single
z& is type Long
name$ is type String

#######################################################################
From VBA 6.3 Help File
#######################################################################

Visual Basic Naming Rules

Use the following rules when you name procedures, constants, variables,
and arguments in a Visual Basic module:

You must use a letter as the first character.

You can't use a space, period (.), exclamation mark (!), or the
characters @, &, $, # in the name.

Name can't exceed 255 characters in length.

Generally, you shouldn't use any names that are the same as the
functions, statements, and methods in Visual Basic. You end up shadowing
the same keywords in the language. To use an intrinsic language
function, statement, or method that conflicts with an assigned name, you
must explicitly identify it. Precede the intrinsic function, statement,
or method name with the name of the associated type library. For
example, if you have a variable called Left, you can only invoke the
Left function using VBA.Left.

You can't repeat names within the same level of scope. For example, you
can't declare two variables named age within the same procedure.
However, you can declare a private variable named age and a
procedure-level variable named age within the same module.

Note Visual Basic isn't case-sensitive, but it preserves the
capitalization in the statement where the name is declared.

#######################################################################

Just my opinion: I would MUCH rather maintain code that had varialbes
named TotalBalance, Index, MontlyPayment, CurrentBalance instead of
variable named tb@, i$, mp@, cb@, etc. While it does require less
typing (no pun intended) while initially writing the code, it can become
difficult to understand when someone else picks up the code two years
later to maintain it (be there, done that).

[tux792]

The type designators are separate from the variable names. The name may be anything you want it to be. The typing designator symbol is only required within the DIM statement. Once you are into the declarations or code body, you drop the symbols and use the variable names as usual...no special characters or designation symbols required.

Rewrite you sample Sub, removing the type-designators from the variables, as in TypeName(i) instead of TypeName(i%), and the Debug listing remains the same. Once a user variable is type casted, the casting symbol is no longer required. These are Type Casting symbols, not naming symbols.

I agree with your naming conventions, as I also use defining named variables. I only use single characters for counts and stepping through loops. What I posted was only a simplistic example to illustrate the issue.

Thank you for your assistance. Your responses have helped me work through my original question of determining Excel's Data-type casting symbols.

! = Single Precision
% = Integer
& = Long Integer
@ = Currency
# = Double Precision
$ = String

Regards,
Tux792