I am still trying to understand the thinking behind certain things in VBA.

Can anyone explain why to make a cell bold and italic the following is done:

Range("A1").Font.Bold = True
Range("A1").Font.Italic = True

Rather than:

Range("A1").Font = xlBold + xlItalic

I can see that Bold is just one of the properties of the font and you either
switch it on or off. So the way it is implemented is absolutely logical. But
why is the other way of doing it illogical then?

Geoff

Range("A1").Font = xlBold + xlItalic

A font has many properties. Besides the above it has "name", "size",
"color", etc. Do you think your method works better with this wealth of
properties? Also how would you determine (as opposed to assign) what
properties a font has? "Range("A1").Font = xlBold" would be False since it
is "xlBold + xlItalic". Yet the font is bold.

--
Jim Rech
Excel MVP

"Jim Rech" wrote in message
...
Range("A1").Font = xlBold + xlItalic

A font has many properties. Besides the above it has "name", "size",
"color", etc. Do you think your method works better with this wealth of
properties? Also how would you determine (as opposed to assign) what
properties a font has? "Range("A1").Font = xlBold" would be False since it
is "xlBold + xlItalic". Yet the font is bold.

--
Jim Rech
Excel MVP

Apparently there at MVP school they don't teach the charm and nuance of bit
masks. Something known and used throughout the rest of the planet.

Assuming a bit mask where one could say xlBold+xlItalic+..., your dilemma
would be resolved thus: '(Range("A1").Font And xlBold)0' .

The buttons parameter of Msgbox works just this way. This is typical of the
annoying inconsistancies with which VB is rife.

Too difficult you cry, this nasty parentheses, the ugly comparison to 0,
gag. If VB and a better grasp of the notions of true and false they wouldn't
be necessary. In fact, any language with a type of 'Boolean' is suspect as
being not a real language but merely a rag tag incoherent collection of ways
to do things. Much like VB.

--
Terry

"I said I never had much use for one,
I never said I didn't know how to use one."
M. Quigley

There is an alternate method, FontStyle:

Worksheets("Sheet1").Range("A1").Font.FontStyle = "Bold Italic"--
Regards,Tom Ogilvy"GB"
wrote in message ...
I am still trying to understand the thinking behind certain things in VBA.

Can anyone explain why to make a cell bold and italic the following is
done:

Range("A1").Font.Bold = True
Range("A1").Font.Italic = True

Rather than:

Range("A1").Font = xlBold + xlItalic

I can see that Bold is just one of the properties of the font and you
either
switch it on or off. So the way it is implemented is absolutely logical.
But
why is the other way of doing it illogical then?

Geoff

Don't assume that someone doesn't know something because he doesn't mention
it in a brief post. I was a proficient assembly language programmer long
before I touched Excel. Anyway, there wasn't much point in mentioning
something that would not apply in this case. Bitmasks are great for
true/false on/off properties but it would be hard to apply them to the Font
property since the value of say Font.Name is a string. All in all I think
the MS developers did a great job with Excel's object model.

--
Jim Rech
Excel MVP

"Jim Rech" wrote in message
...
Range("A1").Font = xlBold + xlItalic

A font has many properties. Besides the above it has "name", "size",
"color", etc. Do you think your method works better with this wealth of
properties? Also how would you determine (as opposed to assign) what
properties a font has? "Range("A1").Font = xlBold" would be False since it
is "xlBold + xlItalic". Yet the font is bold.

--
Jim Rech
Excel MVP


Noted. I had in mind Terry's point about MsgBox when I asked the question.

The point is not so much about whether the object model is well laid out but
about making VBA more accessible to those starting out. Code developers (and
MVPs) are unsuitable people to see things from that perspective. The object
model may be beautifully formed, but that does not make it easy to learn.

I think that the VBA compiler should take a pretty unambiguous statement on
a line by itself such as "Range("A1").Font = xlBold" and make more of it
than just an error message. Maybe it needs to say "Do you mean ......?"

Incidentally, I wrote one of my first computer programmes in machine code -
not assembler - 37 years ago when I was still at school. I am a
highly-qualified professional end-user, not a dedicated computer buff, and I
just need to use VBA as one of the tools of my trade. I am disappointed that
VBA isn't easier to learn. I do not want to dedicate my life to it!

Geoff

"Jim Rech" wrote in message
...
Don't assume that someone doesn't know something because he doesn't
mention
it in a brief post.

No, sport, I assumed you didn't know something because you responded that
something that works just fine thank you in the rest of the galaxy wouldn't
work properly there in your village. It wasn't lack of information, it was
erroneous information.

I was a proficient assembly language programmer long
before I touched Excel.

Doubtful. Not that you did it, but that you were profcient at it.

Anyway, there wasn't much point in mentioning
something that would not apply in this case. Bitmasks are great for
true/false on/off properties but it would be hard to apply them to the
Font
property since the value of say Font.Name is a string.

Twaddle. What possible effect could the constituency of Font.X have on
Font.Y if you didn't want it to have any?

All in all I think
the MS developers did a great job with Excel's object model.

You're setting off my bull**** detector. Most object nonsense is contrived
and gratuitous. The actual need for it is minuscule. Religious addiction to
object models lead to exactly what windows and it's various pieces are.
Incoherent collections of ways to do things that sort of work sometimes.
It's a way to do something, it sure as hell isn't the only way nor is it
necessarily the best way. Just a way.

You give every appearance, like many of your fellow travelers in this
sandbox, to possess prodigious knowledge of Excel and it's environment. This
is a Good Thing, and I'm glad that you're about and willing to share. I kid
you not.

But, from what I've seen in these waters, that there isn't a one of you
capable of writing commercial grade code or understanding the nuances
thereof. This doesn't seem to prevent any of you from holding forth as if
you do. There is always someone who knows less than you about something and,
oh happy day, if you can rustle up someone who knows nothing at all then
anything can look a whole hell of a lot like everything to that poor
creature and you can pose godlike in front of them.

--
Terry

"I said I never had much use for one,
I never said I didn't know how to use one."
M. Quigley