Re: Calling on Methods and Properties within Worksheet Modules
- From: "Ronald R. Dodge, Jr." <ronald.dodge@xxxxxxxxxx>
- Date: Fri, 5 Dec 2008 10:51:53 -0500
The only reason why I can think of doing that, the Object data type is
similar to the Variant data type except it does have to refer to a class
module as an object. With that, instead of the variable being bound at
compile time, it would be bound at run time.
While this may be of benefit, if there comes a time when MS Office goes to
VB.NET base code (Not sure of MS Office 2007 is already like that or not),
then I would like to spend as little time converting code over to VB.NET
format. While VB.NET does allow for the Object data type, it's very
restrictive on what is and what is not allowed. It's already bad enough
that error trapping codes [among other adjustments] would have to be
modified in so many places when going from the VB6 base code to VB.NET base
code. If this happens, a lot of people will be abruptly awakened by the
various restrictions of VB.NET such as can't use the Variant data type, and
must explicitly declare all variables. Wouldn't be able to imply which
parent object such coded variable is refering to nearly as easily as done in
the VB6 base code. When stepping through code, rather than it compiling on
demand, when one makes an adjustment to code while debugging, program is
using the compiled code and the change the develop makes wouldn't take
effect until the code is compiled again. GoTo's and other similar
statements are no longer allowed in the .NET environment. Error trapping is
done via the Try...Catch...Final blocks. MS did this stuff to force people
to use more of the good programming practices, so as when debugging, it's
much easier to catch things. Of course, not all of the good programming
practice rules can be enforced like this as people can still use names
that's not so easy to tell what they are, formatting issues, and what ever
else there may be.
A couple of the benefits though of VB.NET would be that it would be compiled
into MSIL, so as multiple programming languages can be used for the same
code (in some cases, VB wouldn't be able to be used, but more so C#), and
instead of having to create multiple methods/properties, each method and
property can have multiple signatures.
These are just a few of the several differences between the 2 base codes.
--
Thanks,
Ronald R. Dodge, Jr.
Production Statistician
Master MOUS 2000
"Peter T" <peter_t@discussions> wrote in message
news:eKaOkauVJHA.1200@xxxxxxxxxxxxxxxxxxxxxxx
Why is that?
Try it, I'm sure you will then work out why.
Regards,
Peter T
"Ronald R. Dodge, Jr." <ronald.dodge@xxxxxxxxxx> wrote in message
news:Oqx6sFuVJHA.1200@xxxxxxxxxxxxxxxxxxxxxxx
Why is that? I am a strong believer of good programming practice, which
includes avoiding ambiguities whenever possible, which should be nearly
100% of the time, if not 100% of the time. About the only time I can see
when ambiguity may not be avoided would be dealing with late binding due
to other limitations and the lack of being able to bind at compile time.
--
Thanks,
Ronald R. Dodge, Jr.
Production Statistician
Master MOUS 2000
"Peter T" <peter_t@discussions> wrote in message
news:%23ngtuolVJHA.4092@xxxxxxxxxxxxxxxxxxxxxxx
If I follow what you are trying to say, and it's a highly dubious if!
Declare l_wsh As Object ' note not as worksheet
Regards,
Peter T
"Ronald R. Dodge, Jr." <ronald.dodge@xxxxxxxxxx> wrote in message
news:%23RRbXjjVJHA.4148@xxxxxxxxxxxxxxxxxxxxxxx
From within a class modules, is there a viable way to call on a public
method and/or property that is setup within a worksheet module?
I have setup a procedure with the following signature:
Public Sub pcdInitializeWorksheet(ByRef l_objScheduleRangeNames As
clsScheduleRangeNames)
and within the class module that is attempting to call on it, it's
setup as:
l_wsh.pcdInitializeWorksheet m_objScheduleRangeNames
The object variable "l_wsh" is within a For Each...Next loop, which is
a worksheet object.
At the time it's compiling, it's erroring out stating the above method,
"pcdInitializeWorksheet", is not found. If I comment out that one line
of code, everything compiles just fine.
If it's not feasible to use worksheet modules as such, then I will be
left with no choice but to emulate the worksheets.
--
Thanks,
Ronald R. Dodge, Jr.
Production Statistician
Master MOUS 2000
.
- Follow-Ups:
- References:
- Calling on Methods and Properties within Worksheet Modules
- From: Ronald R. Dodge, Jr.
- Re: Calling on Methods and Properties within Worksheet Modules
- From: Peter T
- Re: Calling on Methods and Properties within Worksheet Modules
- From: Ronald R. Dodge, Jr.
- Re: Calling on Methods and Properties within Worksheet Modules
- From: Peter T
- Calling on Methods and Properties within Worksheet Modules
- Prev by Date: Delete "count" of workbooks?
- Next by Date: Re: If -Then in VBA Code
- Previous by thread: Re: Calling on Methods and Properties within Worksheet Modules
- Next by thread: Re: Calling on Methods and Properties within Worksheet Modules
- Index(es):
Relevant Pages
|