HELP: "Type mismatch" with ActiveX DLL - instancing

[Seb Thirlway]

Hi

I've run into a problem I can't work out:

I've compiled a DLL of useful functions, using VB. It's tested, compiled
and registered OK, and works - or at least some of the functions work.

1.
My problem comes with a function called MoveToFirstRecord, which I've used
in various environments for years - basically, it saves you the hassle of
dealing with empty recordsets: if the recordset is empty, it just returns
False, trapping and discarding the errors that result from trying to read
from the recordset - so the calling code can just act on the False return
value and know not to do anything with the recordset.

I've declared this as Public Function MoveToFirstRecord(p_rs AS
ADODB.Recordset) AS Boolean

The VBScript creates an object (Server.CreateObject) to access this DLL, and
then attempts:

If WebUtil[the object].MoveToFirstRecord(rstResults) Then ....do something
I've altered the script to a "debug" version, which just does

<% = WebUtil.MoveToFirstRecord(rstResults) %>

(rstREsults comes from an Execute on an ADODB.Connection object.)

Every way I try to call MoveToFirstRecord, I get "VBScript error (large
number): type mismatch". What on earth is going on? I tried
TypeName(rstResults) and got "Recordset", so what's going on?

2. Instancing
I made the classes in the DLL GlobalMultiUse. VBScript doesn't seem to like
that - I can't just do MoveToFirstRecord, as opposed to
[object].MoveToFirstRecord - is this just the way it is, or is there
something I'm doing wrong?

Also, I'd like to be able to release the DLL file so I can upgrade it during
development. I've tried everything - unregistering it using regsvr32,
shutting down the Web server, shutting down the Web server and all Internet
Explorer windows - I still can't replace the file, but get a locking error.
This just worries me a bit - I've got so used to treading carefully around
remote references in VB, that I'd like to be sure that doing a Set
Object=Nothing really does allow the DLL to unload.
If the class is GlobalMultiUse, when will the Web server release the DLL?
When the particular ASP script finishes?

any help - thanks!!

Seb Thirlway
s...@thirlway.demon.co.uk

[Jesse Luna]

The short answer is that VBScript only deals with Variant types when talking
to VB. You will have to pass Variant types in arguments. This sucks but
that's the way it is.

Jesse Luna

Seb Thirlway wrote in message
<941820439.6908.0...@news.demon.co.uk>...

[Michael Harris]

Since I've answered this same question so many times, I wrote a generic reply to cut/paste...

Problem:

Calling methods in an ActiveX component from a script client causes "type mismatch" error, but calling the same method from a VB client does not.

Solution:

(using a hypothetical object SomeObject with a SomeMethod method)

The underlying cause is that SomeMethod expects its arguments to be passed ByRef strongly typed (e.g., in VB - ByRef blah As String).  A VB client can Dim and pass strongly typed arguments. But script clients only know Variants.

Variants can't be coerced to strongly typed ByRef arguments but they _can_ be coerced to strongly typed ByVal arguments, and can be passed to ByRef/ByVal Variant arguments without any coercion. This is a limitation of the underlying COM library implementation of the IDispatch interface. It's not an oversight or a bug - it was a conscious design decision.

There are a number of ways to circumvent this limitation. Using a conversion function like cstr() or simply wrapping arguments in ()'s both accomplish the same thing - the argument becomes an expression whose value is (effectively if not literally) passed ByVal rather than ByRef. When passing object references you need to wrap the object reference in ()'s since there's no conversion function for objects.

For example,

SomeObject.SomeMethod cstr(strText), clng(lngNumber), (objThing)

SomeObject.SomeMethod (strText), (lngNumber), (objThing)

are equivalent.

In the long run, if you control the source of SomeObject, then changing SomeMethod to use ByRef Variant arguments is the most "script friendly" solution with strongly typed ByVal arguments being the 2nd best choice. If SomeMethod _must_ have a ByRef argument in order to change the value and return it in the argument list, then a ByRef Variant argument is your _only_ choice.

--
Michael Harris

Seb Thirlway <s...@thirlway.demon.co.uk> wrote in message news:941820439.6908.0...@news.demon.co.uk...