Excel 2003.
Noticed something strange and that is that in my code the casing of
Font.Bold is not like that anymore but instead: Font.bOld
Making it Font.Bold doesn't alter anything, it will revert back to bOld.
I had a look if I maybe had a class or UDT with this property, but I
haven't.
I had a local variable bOld, but changing that to something else made no
difference.
Not sure there is any harm in it, but maybe somebody could explain to me
what is
going on here.

RBS

Hi Bart,

I have noticed this many times. Somehow, VBA seems to keep some record of
it, and maintains it looking like a reference to the variable even when you
change/delete that variable. I have never had a problem with it, even when I
have had a variable with the same name as the property.

--
---
HTH

Bob


(there's no email, no snail mail, but somewhere should be gmail in my addy)



"RB Smissaert" <(E-Mail Removed)> wrote in message
news:(E-Mail Removed)...
> Excel 2003.
> Noticed something strange and that is that in my code the casing of
> Font.Bold is not like that anymore but instead: Font.bOld
> Making it Font.Bold doesn't alter anything, it will revert back to bOld.
> I had a look if I maybe had a class or UDT with this property, but I
> haven't.
> I had a local variable bOld, but changing that to something else made no
> difference.
> Not sure there is any harm in it, but maybe somebody could explain to me
> what is
> going on here.
>
> RBS

Thanks Bob, that is reassuring.
This looks like a bug in VBA to me.
Any idea where this could be stored?
The object browser shows (as expected) the normal casing, Bold.

RBS


"Bob Phillips" <(E-Mail Removed)> wrote in message
news:(E-Mail Removed)...
> Hi Bart,
>
> I have noticed this many times. Somehow, VBA seems to keep some record of
> it, and maintains it looking like a reference to the variable even when
> you change/delete that variable. I have never had a problem with it, even
> when I have had a variable with the same name as the property.
>
> --
> ---
> HTH
>
> Bob
>
>
> (there's no email, no snail mail, but somewhere should be gmail in my
> addy)
>
>
>
> "RB Smissaert" <(E-Mail Removed)> wrote in message
> news:(E-Mail Removed)...
>> Excel 2003.
>> Noticed something strange and that is that in my code the casing of
>> Font.Bold is not like that anymore but instead: Font.bOld
>> Making it Font.Bold doesn't alter anything, it will revert back to bOld.
>> I had a look if I maybe had a class or UDT with this property, but I
>> haven't.
>> I had a local variable bOld, but changing that to something else made no
>> difference.
>> Not sure there is any harm in it, but maybe somebody could explain to me
>> what is
>> going on here.
>>
>> RBS
>
>

Bart,

This is just conjecture upon my part, and I have no idea if it is actually
so, and if so where. Like you, I think it is a bug, no proper clean-up when
variables are deleted.

--
---
HTH

Bob


(there's no email, no snail mail, but somewhere should be gmail in my addy)



"RB Smissaert" <(E-Mail Removed)> wrote in message
news:%(E-Mail Removed)...
> Thanks Bob, that is reassuring.
> This looks like a bug in VBA to me.
> Any idea where this could be stored?
> The object browser shows (as expected) the normal casing, Bold.
>
> RBS
>
>
> "Bob Phillips" <(E-Mail Removed)> wrote in message
> news:(E-Mail Removed)...
>> Hi Bart,
>>
>> I have noticed this many times. Somehow, VBA seems to keep some record of
>> it, and maintains it looking like a reference to the variable even when
>> you change/delete that variable. I have never had a problem with it, even
>> when I have had a variable with the same name as the property.
>>
>> --
>> ---
>> HTH
>>
>> Bob
>>
>>
>> (there's no email, no snail mail, but somewhere should be gmail in my
>> addy)
>>
>>
>>
>> "RB Smissaert" <(E-Mail Removed)> wrote in message
>> news:(E-Mail Removed)...
>>> Excel 2003.
>>> Noticed something strange and that is that in my code the casing of
>>> Font.Bold is not like that anymore but instead: Font.bOld
>>> Making it Font.Bold doesn't alter anything, it will revert back to bOld.
>>> I had a look if I maybe had a class or UDT with this property, but I
>>> haven't.
>>> I had a local variable bOld, but changing that to something else made no
>>> difference.
>>> Not sure there is any harm in it, but maybe somebody could explain to me
>>> what is
>>> going on here.
>>>
>>> RBS
>>
>>
>

It was easy though to make it go back to the normal Font.Bold by adding
this to a normal module, and then deleting it:

Public Type dummy
Bold As Boolean
End Type

Pleased with this as it looked bad.

RBS


"Bob Phillips" <(E-Mail Removed)> wrote in message
news:(E-Mail Removed)...
> Bart,
>
> This is just conjecture upon my part, and I have no idea if it is actually
> so, and if so where. Like you, I think it is a bug, no proper clean-up
> when variables are deleted.
>
> --
> ---
> HTH
>
> Bob
>
>
> (there's no email, no snail mail, but somewhere should be gmail in my
> addy)
>
>
>
> "RB Smissaert" <(E-Mail Removed)> wrote in message
> news:%(E-Mail Removed)...
>> Thanks Bob, that is reassuring.
>> This looks like a bug in VBA to me.
>> Any idea where this could be stored?
>> The object browser shows (as expected) the normal casing, Bold.
>>
>> RBS
>>
>>
>> "Bob Phillips" <(E-Mail Removed)> wrote in message
>> news:(E-Mail Removed)...
>>> Hi Bart,
>>>
>>> I have noticed this many times. Somehow, VBA seems to keep some record
>>> of it, and maintains it looking like a reference to the variable even
>>> when you change/delete that variable. I have never had a problem with
>>> it, even when I have had a variable with the same name as the property.
>>>
>>> --
>>> ---
>>> HTH
>>>
>>> Bob
>>>
>>>
>>> (there's no email, no snail mail, but somewhere should be gmail in my
>>> addy)
>>>
>>>
>>>
>>> "RB Smissaert" <(E-Mail Removed)> wrote in message
>>> news:(E-Mail Removed)...
>>>> Excel 2003.
>>>> Noticed something strange and that is that in my code the casing of
>>>> Font.Bold is not like that anymore but instead: Font.bOld
>>>> Making it Font.Bold doesn't alter anything, it will revert back to
>>>> bOld.
>>>> I had a look if I maybe had a class or UDT with this property, but I
>>>> haven't.
>>>> I had a local variable bOld, but changing that to something else made
>>>> no difference.
>>>> Not sure there is any harm in it, but maybe somebody could explain to
>>>> me what is
>>>> going on here.
>>>>
>>>> RBS
>>>
>>>
>>
>
>

Dim bOld As Boolean
Dim rng As Range
Set rng = ActiveCell
rng.Font.bOld = True

To get back the right casing:

Dim Bold as Boolean


--
Tim Zych
SF, CA


"RB Smissaert" <(E-Mail Removed)> wrote in message
news:(E-Mail Removed)...
> Excel 2003.
> Noticed something strange and that is that in my code the casing of
> Font.Bold is not like that anymore but instead: Font.bOld
> Making it Font.Bold doesn't alter anything, it will revert back to bOld.
> I had a look if I maybe had a class or UDT with this property, but I
> haven't.
> I had a local variable bOld, but changing that to something else made no
> difference.
> Not sure there is any harm in it, but maybe somebody could explain to me
> what is
> going on here.
>
> RBS

LOL! never thought of that. I have experienced it most with Mid, where I
have declared a variable of mID. Even declaring it as a simple variable
corrects it back. I will remember this.

--
---
HTH

Bob


(there's no email, no snail mail, but somewhere should be gmail in my addy)



"RB Smissaert" <(E-Mail Removed)> wrote in message
news:%(E-Mail Removed)...
> It was easy though to make it go back to the normal Font.Bold by adding
> this to a normal module, and then deleting it:
>
> Public Type dummy
> Bold As Boolean
> End Type
>
> Pleased with this as it looked bad.
>
> RBS
>
>
> "Bob Phillips" <(E-Mail Removed)> wrote in message
> news:(E-Mail Removed)...
>> Bart,
>>
>> This is just conjecture upon my part, and I have no idea if it is
>> actually so, and if so where. Like you, I think it is a bug, no proper
>> clean-up when variables are deleted.
>>
>> --
>> ---
>> HTH
>>
>> Bob
>>
>>
>> (there's no email, no snail mail, but somewhere should be gmail in my
>> addy)
>>
>>
>>
>> "RB Smissaert" <(E-Mail Removed)> wrote in message
>> news:%(E-Mail Removed)...
>>> Thanks Bob, that is reassuring.
>>> This looks like a bug in VBA to me.
>>> Any idea where this could be stored?
>>> The object browser shows (as expected) the normal casing, Bold.
>>>
>>> RBS
>>>
>>>
>>> "Bob Phillips" <(E-Mail Removed)> wrote in message
>>> news:(E-Mail Removed)...
>>>> Hi Bart,
>>>>
>>>> I have noticed this many times. Somehow, VBA seems to keep some record
>>>> of it, and maintains it looking like a reference to the variable even
>>>> when you change/delete that variable. I have never had a problem with
>>>> it, even when I have had a variable with the same name as the property.
>>>>
>>>> --
>>>> ---
>>>> HTH
>>>>
>>>> Bob
>>>>
>>>>
>>>> (there's no email, no snail mail, but somewhere should be gmail in my
>>>> addy)
>>>>
>>>>
>>>>
>>>> "RB Smissaert" <(E-Mail Removed)> wrote in message
>>>> news:(E-Mail Removed)...
>>>>> Excel 2003.
>>>>> Noticed something strange and that is that in my code the casing of
>>>>> Font.Bold is not like that anymore but instead: Font.bOld
>>>>> Making it Font.Bold doesn't alter anything, it will revert back to
>>>>> bOld.
>>>>> I had a look if I maybe had a class or UDT with this property, but I
>>>>> haven't.
>>>>> I had a local variable bOld, but changing that to something else made
>>>>> no difference.
>>>>> Not sure there is any harm in it, but maybe somebody could explain to
>>>>> me what is
>>>>> going on here.
>>>>>
>>>>> RBS
>>>>
>>>>
>>>
>>
>>
>

"RB Smissaert" <(E-Mail Removed)> wrote in message
news:%(E-Mail Removed)...
> Thanks Bob, that is reassuring.
> This looks like a bug in VBA to me.
> Any idea where this could be stored?
> The object browser shows (as expected) the normal casing, Bold.
>
> RBS
>

As Mr. Phillips noted it is common enough - but not so common that it isn't
surprising when it happens.

It comes about because of the "interpreted" nature of VBA, and the complex
symbol tables VBA creates as it flows along (during development). This is
'stored' as pcode or sometimes called OpCode in the VBA world. Just as in VB
the 'text' portion of the code that you see in the editor is actually a View
to the underlying pcode. When you type something VBA immediately parses it
(syntax checking, symbol table comparisons, etc.) and converts it to pcode,
this pcode is immediately converted back to text and presented back to the
User. That's where the spelling change happens. (Happens quick doesn't it.
<g>)

[The same thing is happening in VB.]

When doing your own research note that there two subtle flavors of 'OpCode'
in VBA - OpCode and ExCode. OpCode refers to pcode within an Editor. ExCode
refers to pcode that is packaged up and ready to 'run' - precompiled pcode.
For example while you have a module open in the editor the code behind is
OpCode. Once you save the module it gets wraps with additional material, is
rearranged a bit and becomes ExCode. Or to some - ExCode plus OpCode. That
is best left up to the geeks as this is a rather fine distinction since to
us it is just pcode. <g>

While developing a lot of crap builds up. (technical term for additional
information no longer needed). You can get rid of most of this stuff, by
periodically running the module - convert the 'OpCode' to 'ExCode'. You
don't have to excise the whole module just call some subroutine in it.

[That's why in VB a periodic "Start with Full Compile" helps to keep it
'clean', and removes strange errors.]

There used to be a whole list of "things to do" to clean up code (reset it),
like saving code to a file and reloading it. I don't remember them all -
most were probably wives' tales anyway. <g> Supposedly Office VBA cleaned up
its act with Office 2000 and beyond (more cleanup when converted to ExCode).
There must still be some need because I see the occasional "VBA Decompiler
and Cleaner" being sold. These tools cut down module size and appear to
improve performance so apparently things haven't changed that much. Most
full-blown Office developers own one.

This is really the kind of question you should be asking in an Excel
Developer's group. They fool with this on a daily basis.

hth
-ralph

Yes, found out, as you say even a simple local variable will make it go back
to normal.
Somehow it must be stored in the particular workbook as other workbooks are
not
affected and closing and re-opening Excel doesn't make it go away.
Had a look in VB6 and it does the same.

RBS


"Tim Zych" <tzych@NOSp@mE@RTHLINKDOTNET> wrote in message
news:(E-Mail Removed)...
> Dim bOld As Boolean
> Dim rng As Range
> Set rng = ActiveCell
> rng.Font.bOld = True
>
> To get back the right casing:
>
> Dim Bold as Boolean
>
>
> --
> Tim Zych
> SF, CA
>
>
> "RB Smissaert" <(E-Mail Removed)> wrote in message
> news:(E-Mail Removed)...
>> Excel 2003.
>> Noticed something strange and that is that in my code the casing of
>> Font.Bold is not like that anymore but instead: Font.bOld
>> Making it Font.Bold doesn't alter anything, it will revert back to bOld.
>> I had a look if I maybe had a class or UDT with this property, but I
>> haven't.
>> I had a local variable bOld, but changing that to something else made no
>> difference.
>> Not sure there is any harm in it, but maybe somebody could explain to me
>> what is
>> going on here.
>>
>> RBS
>
>

> This is really the kind of question you should be asking in
> an Excel Developer's group

Did some quick testing and it looks to me that VB6 behaves exactly the same.
So, not sure now if your explanation to do with OpCodea and ExOpCode
explains it all.

RBS


"Ralph" <(E-Mail Removed)> wrote in message
news:%(E-Mail Removed)...
>
> "RB Smissaert" <(E-Mail Removed)> wrote in message
> news:%(E-Mail Removed)...
>> Thanks Bob, that is reassuring.
>> This looks like a bug in VBA to me.
>> Any idea where this could be stored?
>> The object browser shows (as expected) the normal casing, Bold.
>>
>> RBS
>>
>
> As Mr. Phillips noted it is common enough - but not so common that it
> isn't
> surprising when it happens.
>
> It comes about because of the "interpreted" nature of VBA, and the complex
> symbol tables VBA creates as it flows along (during development). This is
> 'stored' as pcode or sometimes called OpCode in the VBA world. Just as in
> VB
> the 'text' portion of the code that you see in the editor is actually a
> View
> to the underlying pcode. When you type something VBA immediately parses it
> (syntax checking, symbol table comparisons, etc.) and converts it to
> pcode,
> this pcode is immediately converted back to text and presented back to the
> User. That's where the spelling change happens. (Happens quick doesn't it.
> <g>)
>
> [The same thing is happening in VB.]
>
> When doing your own research note that there two subtle flavors of
> 'OpCode'
> in VBA - OpCode and ExCode. OpCode refers to pcode within an Editor.
> ExCode
> refers to pcode that is packaged up and ready to 'run' - precompiled
> pcode.
> For example while you have a module open in the editor the code behind is
> OpCode. Once you save the module it gets wraps with additional material,
> is
> rearranged a bit and becomes ExCode. Or to some - ExCode plus OpCode. That
> is best left up to the geeks as this is a rather fine distinction since to
> us it is just pcode. <g>
>
> While developing a lot of crap builds up. (technical term for additional
> information no longer needed). You can get rid of most of this stuff, by
> periodically running the module - convert the 'OpCode' to 'ExCode'. You
> don't have to excise the whole module just call some subroutine in it.
>
> [That's why in VB a periodic "Start with Full Compile" helps to keep it
> 'clean', and removes strange errors.]
>
> There used to be a whole list of "things to do" to clean up code (reset
> it),
> like saving code to a file and reloading it. I don't remember them all -
> most were probably wives' tales anyway. <g> Supposedly Office VBA cleaned
> up
> its act with Office 2000 and beyond (more cleanup when converted to
> ExCode).
> There must still be some need because I see the occasional "VBA Decompiler
> and Cleaner" being sold. These tools cut down module size and appear to
> improve performance so apparently things haven't changed that much. Most
> full-blown Office developers own one.
>
> This is really the kind of question you should be asking in an Excel
> Developer's group. They fool with this on a daily basis.
>
> hth
> -ralph
>
>