Why so much non-OOP syntax in VBA?
 

Excel 2002 VBA newbie Q:

Looking at just one object, there is a "UserForm.Hide" but seemingly
no "UserForm.Close" method. Examples in this newsgroup seem to use
"Unload UserForm". I mean, huh?

I sure see an awful lot of this non-OOP syntax thruout VBA. Does full-
blown VB rely on it as well?

If so, is there a good reason why one shouldn't consider this pre-
Columbian mishmash, well, pathetic?

Thanks.

***

Why so much non-OOP syntax in VBA?
 

If VBA were rational it would not be as much fun!
--
Gary''s Student - gsnu2007h


" wrote:

Excel 2002 VBA newbie Q:

Looking at just one object, there is a "UserForm.Hide" but seemingly
no "UserForm.Close" method. Examples in this newsgroup seem to use
"Unload UserForm". I mean, huh?

I sure see an awful lot of this non-OOP syntax thruout VBA. Does full-
blown VB rely on it as well?

If so, is there a good reason why one shouldn't consider this pre-
Columbian mishmash, well, pathetic?

Thanks.

***

Why so much non-OOP syntax in VBA?
 

VB is not a true OOP language. It does not even support inheritance. While
you can create classes OOP is more of an added on feature than an inherant
characteristic of the language.
--
HTH...

Jim Thomlinson


" wrote:

Excel 2002 VBA newbie Q:

Looking at just one object, there is a "UserForm.Hide" but seemingly
no "UserForm.Close" method. Examples in this newsgroup seem to use
"Unload UserForm". I mean, huh?

I sure see an awful lot of this non-OOP syntax thruout VBA. Does full-
blown VB rely on it as well?

If so, is there a good reason why one shouldn't consider this pre-
Columbian mishmash, well, pathetic?

Thanks.

***

Why so much non-OOP syntax in VBA?
 

Well, not sure how good of an explanation this will be, but I can hit on
some of it. The why's and wherefore's I probably can't though. The
Load/Unload statements are for claiming and releasing objects from memory,
which is a *good* thing for managed code, well, more or less the basis for
managed code being "managed" (by the CLR:
http://en.wikipedia.org/wiki/Common_Language_Runtime). VBA is an OOP
language. In this specific instance you're referring to, you're using a
Statement which releases an Object. This is opposed to having an Object and
using/setting Properties or Controls from that Object. So while it may seem
that you are indeed controlling an Object (a UserForm in this case) you are,
but you are doing so from a Statement, which is not a control/property from
that particular Object, but the Object Model itself.

Does that make sense? Probably not. I'm sure there are other great minds
who could explain it much better than I. VBA offers a full, rich OM. Being
managed code and object oriented, there is much versatility that we have.
There is no substitute for knowing the OM though, and all code languages
have their own nuances and intricacies. I'm not saying VBA is perfect, but
IMO it is a well-rounded language. I wouldn't consider VBA pre-Columbian,
nor mishmash, and certainly not pathetic. But it is, alas, in the eye of
the beholder. <g

HTH

Regards,
Zack Barresse
wrote in message
...
Excel 2002 VBA newbie Q:

Looking at just one object, there is a "UserForm.Hide" but seemingly
no "UserForm.Close" method. Examples in this newsgroup seem to use
"Unload UserForm". I mean, huh?

I sure see an awful lot of this non-OOP syntax thruout VBA. Does full-
blown VB rely on it as well?

If so, is there a good reason why one shouldn't consider this pre-
Columbian mishmash, well, pathetic?

Thanks.

***

Why so much non-OOP syntax in VBA?
 

wrote in message
...

Excel 2002 VBA newbie Q:

Looking at just one object, there is a "UserForm.Hide" but seemingly
no "UserForm.Close" method. Examples in this newsgroup seem to use
"Unload UserForm". I mean, huh?

I sure see an awful lot of this non-OOP syntax thruout VBA. Does full-
blown VB rely on it as well?

VB6 and earlier, yes. Welcome to the world of legacy and backwards
compatibility.