Zugg Software :: View topic

Posted: Mon Oct 04, 2004 11:23 pm

Who comes up with this kind of crap? Why can't we just all agree on a SINGLE value to represent an unassigned variable. I am pulling my hair out over all of this.

Here's the deal...Objects in eMobius, like the zFolder object implement a specific COM Interface (IzFolder in this case). One of the properties of this specific object is Messages. This property is supposed to return a Collection of Message objects. So, the return type for this property is IzCollection (a COM object that implements the zCollection interface).

What if there is no collection to return? (an empty folder). Well, in Delphi, you return the value NIL which is an empty pointer. All Interfaces like IzCollection are pointer objects.

But VBScript doesn't have a NIL value. Instead, it has a NULL value and a routine to test this called IsNull. But this is implemented as a VARIANT data type.

So, Delphi returns an INTERFACE with a value of NIL, and in VBScript, this is NOT NULL. In fact, when you test a NIL Interface in VBScript, you get the following:

IsNull = false
IsEmpty = false
IsObject = true

In other words, VB Script thinks this is a valid COM object. Of course, as soon as you try to call any properties or methods of the object, you get the stupid error "Object required".

Turns out there is yet another test in VBScript: "is nothing". You can do something like:

if (Folder.Messages is nothing) then ...

The "nothing" value in VB Script is a COM Interface with a NIL value, which is what we want.

The confusion is that some COM properties return Variants, and some return Interfaces. For Variants you have to use IsNull and for Interfaces you have to use "is nothing". If you mix these up, you get all sorts of very obscure error messages.

Why couldn't they have just made this work the way it obviously should. A NIL Interface should be compatible with a NULL Variant. This is just really stupid, and I spend hours today trying to find out how this works because the "is nothing" isn't documented anywhere in my "VBScript in a Nutshell" book that I could find.

Sure, once you know about the "is" operator, then you can look it up. But who would have ever thought to look there? I ended up learning about this finally via some Google searches, and even that wasn't as straightforward as I expected.

Sigh.

I also spent a couple hours tracking down another Cleanup problem with COM objects. Turned out to be pretty obscure. The scripting host saves the last result from any function call. So, if you have a function that returns a COM object, but when you call it in VBScript you call it as a method and just let the result get tossed away, then the scripting host still has a reference to the result, even though VBScript doesn't.

Once I added another Cleanup routine to the scripting host and freed up the saved LastResult value, then the problem went away. But it sure was hard to find. I really wish this stupid error message about "There are still active COM objects..." would actually tell you WHAT COM Object is still active.

Anyway, today has been a very frustrating day.

Magician Joined: 13 Oct 2000 Posts: 463

Crap like that is why they rewrote it and called it .NET. :-) While I understand your reasons for using the MS Scripting component over your other options, there will be inevitable issues resulting from using an abandoned, no-source-available component.

Posted: Mon Oct 11, 2004 6:21 pm

Yep. Although I'd be interested in seeing if .NET *really* fixes this. Does VB.NET do all of this in a consistent way, or do they still distinguish between NULL and Nothing?

Also, while MS Scripting has been abandoned by MS, we won't see the replacement till Longhorn, which is still a ways off and I doubt they will make the new .NET scripting language available to older versions of Windows. And how about all of the people that are currently using scripts written using the Windows Scripting Host for sysadmin and various tasks?

I'm not sure customers are going to be as willing to embrace a new scripting technology and throw out their old scripts and upgrade all of their computers for this. That's why I think some people will be interested in Zeus, which will do similar things and yet work on all versions of Windows.

It's good that MS is working to fix this kind of stuff, but it amazes me that it's allowed to happen in the first place. It just shows sometimes how thrown-together some of there software really is. It couldn't have been that difficult to make a Null COM object return true for the IsNull call. But once they make that mistake when COM support was added to VB Script, they are then stuck with it forever for backwards compatibility.

Magician Joined: 13 Oct 2000 Posts: 463

A lot of stupid decisions like this get made for one of two reasons... performance needs, or backwards compatibility/historical reasons. I don't know which this was, but I'd guess backwards compatibility... but MIXED backwards compatibility, like they took existing features from two different areas. Dunno.

All companies make stupid mistakes. MS makes them no more than other places. But I've noticed that MS tends to be MUCH slower to fix stupid mistakes, partly because of a nearly religious devotion to backwards compatibility. Once stupid, always stupid, until they come out with a completely new product... and often, that new product works BOTH ways, the stupid way and the right way. Hence, MS bloatware.

However... what other OS lets you run an application written 25 years ago? Not many. There are advantages to the MS way. Excuse me while I go blow half an hour shooting down CGA biplanes in redbaron.com (and I mean the file extension, not the website).