Case Change By Itself in VBA Code - Help

[Gary]

I am using Access 2000 sp3 with XP Pro OS. When I make my declaration like

Dim i As Integer

After saving my VBA code, when I go back to my VBA code, I notice that
sometimes my Dim i gets changed to Dim I. It its captialized.

Is there something that I am not doing correctly or some setting???

Please help!!

Thanks You,

Gary

 

[Banana]

I had something similar to that happen to me both ways. (e.g. DAO would
change to dao).

That said, though the behavior is definitely a bug, it's a mostly
harmless bug because the code will continue to work whether it's a i or
I, so I just don't worry about it.

For the record, though, I recall that the capitalization can be
influenced by other coding. For example, if you have a MyVariable
declared at the module level, then use a variable named myvariable in a
procedure, it will be re-capitalized to whatever the module declaration
had. Basically what was set first, takes precedence and you can't change
until you delete all references to the same identifier.

But as I said, it's really benign so I don't even bother.

 

[Jack Leach]

I have a constant problem with this using Enums. If I don't type the enum in
the exact case that I declared it in, every instance of it will update to
whatever most recently typed. This is not problematic, but the readability
of the code is sometimes effected, and (lazy me) it takes more time to ensure
the case is typed correctly.

Occasionally I will see this happen from one variable to another when they
are in different procedures... again it's never bothered anything that I can
tell. It is mildly annoying, and sometimes tends to make me a little uneasy
knowthing that two scopes that should have nothing to do with each other are
being referenced somehow. Never had any ill effects on the code itself
though.

Once a while back I questioned the group about the Enum case resetting, but
nobody was able to provide any reason why. Still deal with it to this day.

--
Jack Leach
www.tristatemachine.com

"I haven't failed, I've found ten thousand ways that don't work."
-Thomas Edison (1847-1931)

 

[Klatuu]

What both of you are experiencing is not a bug. That is the way the VBE
works. In the case of the i becoming I, it means you have not dimmed the i.
The case is changed to be the same as when the variable was declared. As to
reserved words, it changes them to be the case as they are defined.

 

[Jack Leach]

I'm not sure I understand. For instance, if I have the following code:

Public Enum eRecordStatus
dsrsActive = 0
dsrsArchived = 1
dsrsPending = 2
End Enum


and after this is compiled and I type anywhere in the project:

something = dsrspending

it *should* change the case of dsrspending to dsrsPending (indicating that I
do indeed have this combination of characters in scope somewhere), but
instead will change every instance of dsrsPending in the project to
dsrspending.

In every other case I explicitly type all constant, variable and procedure
names in lowercase so that if the VBE does not properly case them I know that
I have mistyped the variable name.

--
Jack Leach
www.tristatemachine.com

"I haven't failed, I've found ten thousand ways that don't work."
-Thomas Edison (1847-1931)

 

[Klatuu]

dsrsPending is not dimmed.

 

[Banana]

I'm not sure this was the case. I, too, have observed the behavior where
Enum's members' case do not get preserved correctly whereas built-in
Enum members can preserve the case.

To illustrate further the problem using Jack's example:

Public Enum eRecordStatus
dsrsActive = 0
dsrsArchived = 1
dsrsPending = 2
End Enum


.... <in some random procedure>

Debug.Print eRecordStatus.dsrsPending

If we type out the enum name and use the intellisense to select the
member of the enum, we get the correct case. However if we were to
ignore the intellisense and type the whole thing:

Debug.Print eRecordStatus.dsrspending

What would happen is in the declaration for the Enum, the dsrsPending
member inherits the new case as I just typed.

Note that eRecordStatus.dsrsPending and dsrsPending both are basically
equivalent and will return the same value (2) without having to dim the
member in a procedure (and without testing, I would think it would not
be correct to re-dim a member in each procedure, just like we don't have
to re-dim built-in enum members such as dbOpenDynaset or dbOpenSnapshot,
both which preserve their case correctly.)

To my mind, this is absolutely a bug. I would be glad to concede that in
case of variable i changing to I or vice versa because it was not
properly dimmed, then that's the developer's fault. However, as I've
stated, I've worked on some projects where even built-in library seem to
lose their case (e.g. DAO.Recordset => dao.Recordset).

There is no apparent ill effects; all it does is annoy the heck out of
me as I usually use casing to signal that I've entered my variables
correctly.

 

[Marshall Barton]

OR, at some time it was declared without the capital
letters.

Try adding
Public dsrsPending
at the top of a module and see what happens. Then delete
that line.

 

[Jack Leach]

Try adding

Public dsrsPending
at the top of a module and see what happens. Then delete
that line.

"Compile error: Ambiguous name detected"

The act of enumerating these constants (that is what they're called,
correct? even if there are inside an enum rather than declared as Const), I
would think this would sufficiently Dim them, being that there's no other way
to do it.


In a brand new db:

Public Enum eConsts
dscsactive = 3
dscsArchived = 6
End Enum

compile->save

type ?dscsactive into the immediate and what was in the module as dscsActive
is now as you see above... dscsactive


Not a huge deal either way, really, but I don't think this is caused by my
failure to properly dim the enum'd constant, as there is no other way to do
it. And these values have never been declared anywhere else with a lowercase
format.


Access V11.5614.5606

I have a pending update for Access... maybe they fixed it

--
Jack Leach
www.tristatemachine.com

"I haven't failed, I've found ten thousand ways that don't work."
-Thomas Edison (1847-1931)

 

[Marshall Barton]

Sorry Jack, I seem to have garbled my reply. I haven't used
Enum in ages and was attempting to reply to Gary's initial
problem when I used your varriable name instead of his i
variable.