Re: Writing my 1st VBS "Script Component"



I'm not sure you understood my point. All I was saying is
I never use objects derived from other objects after the
source object is vacated; I always vacate the drived object first.

I was looking for your agreement that this practice would avoid
the problem you described in your original comments. In that
example, you did something I would never do.


I'd go along with that. Anyone who returns
a non-creatable object via object A, and then
dereferences object A, should expect trouble -
legal or not. It's also confusing to code that way,
implying that one is not keeping track of created
objects.

In script, though, MS has tried to make it very
easy, and the "Scripting Guys", the official MS script
experts, even recommend *against* setting objects
to Nothing! By implication they're recommending
that you not bother keeping track of memory usage
at all... that such things are not proper topics of
reflection for scripters.
It's really not much different in VB. Microsoft's effort
to keep things simple can get very confusing when one
decides to do any drawing outside the lines. (They
actually hid ObjPtr, StrPtr and VarPtr, after all, so that
VB6 users wouldn't be made aware of such things as
direct memory access.)

I generally try to get the IntelliSense to work as a practical
matter while writing code; it prevents many mistakes. Also,
it reassures me that my various enumerated constants work,
etc., without having to include a constants file (although this
is sometimes a better choice for speed).

I don't use ASP, so I'm not certain about best methods,
but you mentioned using VB. Wouldn't it make more sense
to just make components in VB rather than start getting
into something as dubious as pseudo-COM registered text files?
I assume you'd get intellisense with an ActiveX DLL. It would
also be a great deal more efficient, if you have work-
intensive functions where speed matters.


As far as I can tell, this is the only newsgroup to talk to for the
ASP Classic (i.e., not dotNET) IIS environment with VBScript. Is
there another one, a better one? {I know 10 years seems like
a long time to twenty-somethings, but is a ~friggin' blink of an
eye to us normal people.}


Indeed. But it's 10 years worth of sales opportunities for
Microsoft, if they can replace usable product with new product.
And it's 3.3 product cycles for their Software Assurance racket.
On the bright side, if you'd switched to .Net you'd already be 3
versions behind by now. :)

As you mentioned earlier, MS is phasing out a lot of
things, in their attempt to increase sales. But actually,
much of it is still going.

VBS is apparently being phased out, but there's a WSH
version for Vista.

VB6 is dead, but it's supported in Vista.

.Net has been going for 6 years now, and it's going nowhere
fast - allegedly designed for "web apps" that aren't happening
and supporting an ever-decreasing number of OSs.

COM is dead, but it's in Vista - which is more than can
be said for .Net. As I understand it, they put a couple of
token .Net files in Vista so that they could say it's in there,
but they knew better (or at least learned better) than to
build an operating system out of bloated, superfluous
wrappers on top of the API.

Now nobody wants Vista anyway, and companies are
dropping out of Software Assurance. So to stem the tide,
MS is announcing that "Windows 7" will be released in just
3 years. Just in time to be a free upgrade to anyone
"smart" enough to stick with Software Assurance!

...It all just keeps getting more loopy.

I suspect that the current endgame for .Net is simply
to kick out all 3rd-party programmers from the API into a
sandbox where Hollywood and music companies won't have
to worry about their DRM being fiddled with, and
advertisers won't have to worry about their ads being
blocked.
( http://arstechnica.com/news.ars/post/20070717-microsoft-patents-the-mother
-of-all-adware-systems.html )

I'm afraid the days of Windows as a viable OS are
numbered... Apparently there's just not enough
money in it. :)


.