•
•
•
•
What is DaniWeb IT Discussion Community?
You're currently browsing the Pascal and Delphi section within the Software Development category of DaniWeb, a massive community of 423,647 software developers, web developers, Internet marketers, and tech gurus who are all enthusiastic about making contacts, networking, and learning from each other. In fact, there are 3,136 IT professionals currently interacting right now! Registration is free, only takes a minute and lets you enjoy all of the interactive features of the site.
Please support our Pascal and Delphi advertiser: Programming Forums
Views: 9733 | Replies: 4
 |
•
•
Join Date: Jan 2005
Posts: 4
Reputation: 
Rep Power: 0
Solved Threads: 0
Newbie Poster
Help With Data-type Declaration Symbols 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
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
•
•
Join Date: Jan 2005
Posts: 31
Reputation:
Rep Power: 4
Solved Threads: 0
Light Poster
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
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
•
•
Join Date: Jan 2005
Posts: 4
Reputation:
Rep Power: 0
Solved Threads: 0
Newbie Poster
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
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
•
•
•
•
Originally Posted by 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
•
•
Join Date: Jan 2005
Posts: 31
Reputation:
Rep Power: 4
Solved Threads: 0
Light Poster
I did verify your findings:
Output:
i% is type Integer
x! is type Single
z& is type Long
name$ is type String
#######################################################################
From VBA 6.3 Help File
#######################################################################
#######################################################################
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).
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).
•
•
Join Date: Jan 2005
Posts: 4
Reputation:
Rep Power: 0
Solved Threads: 0
Newbie Poster
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
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
|
•
•
•
•
•
•
•
•
DaniWeb Pascal and Delphi Marketplace
•
•
•
•
Currently Active Users Viewing This Thread: 1 (0 members and 1 guests)
Linear Mode
- Working with SQL server's Image data type (ASP.NET)
- help understanding "char" data type (C++)
- Working with SQL's Text data type (ASP.NET)
- Text data type troubles in T-SQL (Database Design)
Other Threads in the Pascal and Delphi Forum
- Previous Thread: School assignment in pascal
- Next Thread: Setiing Field width in a record
