Using ATL COM objects with scripting languages 
Author Message
 Using ATL COM objects with scripting languages

We discovered an interesting twist with ASP ( and, therefore I assume
VBScript and JScript).  Our COM objects, implemented with ATL and Visual C++
(latest SP's) have severe limitations in [in,out] and [out] parameters.
From trial and error, because we could not find any documentation, an ASP
page using VBScript can have any Automation compatible parameter as an [in]
and as a [out, retval], but [out] and [in,out] need to be VARIANT *.  We are
trying to find out what is special about the [out, retval].  If you look at
the ATL wrapper code, the [out, retval] parameter is passed just like any
other paramter.  If the VBScript was using the ::Invoke method of our
IDispatch interface, aren't all the parameters packed in a array of
variants?  What is perplexing is being able to use IUnknown * and BSTR * for
[out, retval] but not for regular [out].  We have no such problem with VB or
Delphi.

Does the newly release 3.1 version of VBScript address these?  Where do I
find out what 3.1 fixed?  How about some better documentation on the
requirements of developers to harness VBScript and JScript.



Wed, 05 Jul 2000 03:00:00 GMT  
 Using ATL COM objects with scripting languages

Ken,

I thought scripts require IDispatch derived only functions to work...
are you using straight IUnknown derived funcs?

Quote:
>We discovered an interesting twist with ASP ( and, therefore I assume
>VBScript and JScript).  Our COM objects, implemented with ATL and Visual C++
>(latest SP's) have severe limitations in [in,out] and [out] parameters.
>From trial and error, because we could not find any documentation, an ASP
>page using VBScript can have any Automation compatible parameter as an [in]
>and as a [out, retval], but [out] and [in,out] need to be VARIANT *.  We are
>trying to find out what is special about the [out, retval].  If you look at
>the ATL wrapper code, the [out, retval] parameter is passed just like any
>other paramter.  If the VBScript was using the ::Invoke method of our
>IDispatch interface, aren't all the parameters packed in a array of
>variants?  What is perplexing is being able to use IUnknown * and BSTR * for
>[out, retval] but not for regular [out].  We have no such problem with VB or
>Delphi.

>Does the newly release 3.1 version of VBScript address these?  Where do I
>find out what 3.1 fixed?  How about some better documentation on the
>requirements of developers to harness VBScript and JScript.

Charles Steinhardt[MVP]


Thu, 06 Jul 2000 03:00:00 GMT  
 Using ATL COM objects with scripting languages

Quote:

> I thought scripts require IDispatch derived only functions to work...
> are you using straight IUnknown derived funcs?

> >variants?  What is perplexing is being able to use IUnknown * and BSTR *
for
> >[out, retval] but not for regular [out].

No, he said he could return a IUnknown* (using [out, retval]) from a
function. It is perfectly OK with VB Script as long the object also
implements IDispatch.

Bibhas Bhattacharya



Thu, 06 Jul 2000 03:00:00 GMT  
 Using ATL COM objects with scripting languages

All our interfaces are dual.  IUknown is a OLE automation compatible type
and therefore should be usable as a variable.  One object can be interacting
with another object, independent of scripting languages.  For instance when
a VB Script calls the SaveDoc method of an object, internally, that object
calls other methods in a gateway object that eventually goes across DCOM to
our server.


Quote:
>Ken,

>I thought scripts require IDispatch derived only functions to work...
>are you using straight IUnknown derived funcs?

>Charles Steinhardt[MVP]



Fri, 07 Jul 2000 03:00:00 GMT  
 Using ATL COM objects with scripting languages

You are correct.  For the record:

VBScript 1.0 and all versions of JScript do not support byref (that is,
"out") parameters.
VBScript 2.0 and above supports byref variants only.

The difference between "out" and "out, retval" is as follows:

An "out retval" parameter is the return value of a function.  That is, it is
an actual value, not a reference to a value.  So, if a function returns a
long integer, say, then the caller passes a pointer to a variant to the
callee.  That variant is filled in with the integer and the type is set to
VT_I4.

An "out" parameter is a reference to a value, not a value.  So if there is
an out parameter which is a long integer, then the caller passes a variant
that contains a pointer to an integer owned by the caller.  The callee then
fills in that pointer.

Now, the scripting languages are weakly typed -- there is only one data type
that we use for internal storage, and that's "variant".  So when we see this
code:

x = myobj.myfunction(y)

where y is a byref integer, we pass a pointer to y to myfunction.  But a
pointer to y is a pointer to a variant.  If the callee is expecting a
pointer to an integer, the callee is going to try and cast the pointer,
which is an illegal operation.  Variants are not integers.  That's why we
only support byref variants in VBScript.

JScript doesn't support byref at all -- not for technical reasons, but
because it simply is not part of the language specification.

I hope that clears up any confusion.

Eric

Quote:

>We discovered an interesting twist with ASP ( and, therefore I assume
>VBScript and JScript).  Our COM objects, implemented with ATL and Visual
C++
>(latest SP's) have severe limitations in [in,out] and [out] parameters.
>From trial and error, because we could not find any documentation, an ASP
>page using VBScript can have any Automation compatible parameter as an [in]
>and as a [out, retval], but [out] and [in,out] need to be VARIANT *.  We
are
>trying to find out what is special about the [out, retval].  If you look at
>the ATL wrapper code, the [out, retval] parameter is passed just like any
>other paramter.  If the VBScript was using the ::Invoke method of our
>IDispatch interface, aren't all the parameters packed in a array of
>variants?  What is perplexing is being able to use IUnknown * and BSTR *
for
>[out, retval] but not for regular [out].  We have no such problem with VB
or
>Delphi.

>Does the newly release 3.1 version of VBScript address these?  Where do I
>find out what 3.1 fixed?  How about some better documentation on the
>requirements of developers to harness VBScript and JScript.



Fri, 07 Jul 2000 03:00:00 GMT  
 Using ATL COM objects with scripting languages

You also asked

Quote:
>Does the newly release 3.1 version of VBScript address these?  Where do I
>find out what 3.1 fixed?

(1) No, the byref semantics are the same in VBScript 3.1.

(2) We are working on a document that lists the bugs fixed between 3.0 and
3.1.  It will be posted to www.microsoft.com/scripting when it's done.
Until then, here is a very brief overview of the bugs we fixed:

* A whole bunch of memory leaks.

There were memory leaks in the error handling code, in the WeekdayName and
Monthname functions, and the JScript Enumerator object.

* A whole bunch of far-east win95 fixes for the file system object.

The File System Object family of objects had several fairly obscure bugs
that only reproduced on Japanese Windows95 machines, due to flaws in the
logic when handling the DBCS char set.  There was another bug that caused a
GPF in Folder.CreateTextFile that was fixed as well.

* A bunch of bugs/features in our error handling code.

There was a serious bug in the JScript eval function where code containing
syntax errors would GPF the client.  There was also a situation where an
error message would be generated but not reported.  There was a situation
where an error message could be generated but the string was never freed,
leaking memory.

* A bunch of bugs involving failure during extreme low memory conditions

There were a few code paths where we would allocate memory and not check to
see if the allocation succeeded.  If the allocation happened to fail then
the code could GPF.

* Misc stuff.

Registering both the 16 bit and 32 bit versions of scripting on your machine
messed up the registry -- that's been fixed.  There was a bug in GetObject
that was fixed in build 3.1.2430, which should be up on the web this week --
GetObject would sometimes act like CreateObject instead of GetObject.

Eric

Quote:

>We discovered an interesting twist with ASP ( and, therefore I assume
>VBScript and JScript).  Our COM objects, implemented with ATL and Visual
C++
>(latest SP's) have severe limitations in [in,out] and [out] parameters.
>From trial and error, because we could not find any documentation, an ASP
>page using VBScript can have any Automation compatible parameter as an [in]
>and as a [out, retval], but [out] and [in,out] need to be VARIANT *.  We
are
>trying to find out what is special about the [out, retval].  If you look at
>the ATL wrapper code, the [out, retval] parameter is passed just like any
>other paramter.  If the VBScript was using the ::Invoke method of our
>IDispatch interface, aren't all the parameters packed in a array of
>variants?  What is perplexing is being able to use IUnknown * and BSTR *
for
>[out, retval] but not for regular [out].  We have no such problem with VB
or
>Delphi.

>Does the newly release 3.1 version of VBScript address these?  Where do I
>find out what 3.1 fixed?  How about some better documentation on the
>requirements of developers to harness VBScript and JScript.



Fri, 07 Jul 2000 03:00:00 GMT  
 Using ATL COM objects with scripting languages

Quote:
>Now, the scripting languages are weakly typed -- there is only one data
type
>that we use for internal storage, and that's "variant".  So when we see
this
>code:

Why are scripts weekly typed? Does it cost much to have strong typing?

-Valli



Fri, 07 Jul 2000 03:00:00 GMT  
 Using ATL COM objects with scripting languages

The cost of developing the language engines is not particularly relevant --
yes, developing a strongly typed language is slightly more expensive, but
that is not why VBScript is weakly typed.  Microsoft already produces
strongly typed language products -- Visual Basic and Java.  Users _asked_
for easy-to-learn weak-typed scripting languages based on VB and Java, so we
implemented VBScript and JScript.  There is no point in developing two
languages, Visual Basic and VBScript, with exactly the same language
features!

Eric

Quote:

>>Now, the scripting languages are weakly typed -- there is only one data
>type
>>that we use for internal storage, and that's "variant".  So when we see
>this
>>code:

>Why are scripts weekly typed? Does it cost much to have strong typing?

>-Valli



Sat, 08 Jul 2000 03:00:00 GMT  
 Using ATL COM objects with scripting languages

When I mean Cost, I was refering to cost in terms of performance, memory etc
for the scripting host, i.e the browser.

From a technical standpoint would it be feasible to say support a language
as
full fledged as VB from the browser? As DHTML evolves and people start using
it for
more and more different things, would scripting languages be scaled up? For
example
things like mutidimensional arrays etc.

-Valli


Quote:
>The cost of developing the language engines is not particularly relevant --
>yes, developing a strongly typed language is slightly more expensive, but
>that is not why VBScript is weakly typed.  Microsoft already produces
>strongly typed language products -- Visual Basic and Java.  Users _asked_
>for easy-to-learn weak-typed scripting languages based on VB and Java, so
we
>implemented VBScript and JScript.  There is no point in developing two
>languages, Visual Basic and VBScript, with exactly the same language
>features!

>Eric



Sat, 08 Jul 2000 03:00:00 GMT  
 Using ATL COM objects with scripting languages

I've been thinking more and more about scripting issues, particularly after I had to explain our project to a newer member.  I explained COM services as a better DLL, instead of linking to an export lib or doing run-time binding, to get at the capabilities of the DLL, you get a COM object and its interface to access the capabilities.  With ATL, it makes it easier to wrap a legacy DLL around a common set of services, accessible across the Enterprise, no less.

As I'm testing our server, I'm was using a client testing app in Delphi that uses our COM objects and hitting breakpoints in the server.  Unfortunately, it appears the client testing app has it own bugs.  To get around this, I quickly wrote a Scripting Host script in VBScript.  I can test more, better, faster with complete assurance that I know what is being called and when.  I can't use the majority of our methods because of the [out] IDispatch * problem.

I see more and more people relying on VBScript to tie together code ( previously written as C DLL's, now COM objects).  We need full and complete support for all OLE Automation types.  Yes, I'm aware that to VBScript, all variables are variants, so after executing the IDispatch::Invoke, you won't EASILY know what type to change the variant back to.  I'm not demanding this, I don't expect this anytime soon,  but it has to happen, someday.  No, I don't want to install VB5 to write some test code, have to create projects, workspaces, subdirectories, etc, etc.  Too much debris to keep track of.

Oh well, my two cents worth.


Quote:
>The cost of developing the language engines is not particularly relevant --
>yes, developing a strongly typed language is slightly more expensive, but
>that is not why VBScript is weakly typed.  Microsoft already produces
>strongly typed language products -- Visual Basic and Java.  Users _asked_
>for easy-to-learn weak-typed scripting languages based on VB and Java, so we
>implemented VBScript and JScript.  There is no point in developing two
>languages, Visual Basic and VBScript, with exactly the same language
>features!

>Eric



Sat, 08 Jul 2000 03:00:00 GMT  
 Using ATL COM objects with scripting languages

It seems that it would be a simple enough improvement to VBScript to accept
[out] parameters of ole automation types other than VARIANT.  Since the
destination is always a VARIANT, VBScript could set the VT to that
identified in the TypeInfo for the method about to be called.  The pointer
to the corresponding VARIANT union member would then be passed to the actual
method call.  If the method call fails, the VT could be re-initialized to
VT_EMPTY.

So, how would that make VBScript any more strongly-typed.  I don't see that
it would since, after the method call, the script is still using the [out]
parameter as a VARIANT.  This wouldn't make it any more difficult for the
script programmer, but a whole lot easier for the COM object developers.

Has this approach already been considered for the scripting engines?  If
not, please consider it for the next generation of scripting engines.



Sat, 08 Jul 2000 03:00:00 GMT  
 Using ATL COM objects with scripting languages

Hi guys,

Thanks for your comments.  Rest assured, we are aware of how to implement
this feature.  And it is on a long list of features that we may add to
future versions.  I have no idea when such a feature would actually be
implemented -- I don't control the schedule here.  I'll pass your comments
on to the people who do.

Thanks,
Eric

Quote:

>It seems that it would be a simple enough improvement to VBScript to accept
>[out] parameters of ole automation types other than VARIANT.  Since the
>destination is always a VARIANT, VBScript could set the VT to that
>identified in the TypeInfo for the method about to be called.  The pointer
>to the corresponding VARIANT union member would then be passed to the
actual
>method call.  If the method call fails, the VT could be re-initialized to
>VT_EMPTY.

>So, how would that make VBScript any more strongly-typed.  I don't see that
>it would since, after the method call, the script is still using the [out]
>parameter as a VARIANT.  This wouldn't make it any more difficult for the
>script programmer, but a whole lot easier for the COM object developers.

>Has this approach already been considered for the scripting engines?  If
>not, please consider it for the next generation of scripting engines.



Sun, 09 Jul 2000 03:00:00 GMT  
 Using ATL COM objects with scripting languages

While your passing comments on, please add one more company that would like this
feature.  As it stands now, we have to decide when we develop an interface if we
want that interface to work with VBScript.  Although it's not very hard to do,
we do have to be 'VBScript aware' when developing our interfaces.

Thank you

Chad Henke
Gallagher Financial Systems


Quote:
> Hi guys,

> Thanks for your comments.  Rest assured, we are aware of how to implement
> this feature.  And it is on a long list of features that we may add to
> future versions.  I have no idea when such a feature would actually be
> implemented -- I don't control the schedule here.  I'll pass your comments
> on to the people who do.

> Thanks,
> Eric


> >It seems that it would be a simple enough improvement to VBScript to accept
> >[out] parameters of ole automation types other than VARIANT.  Since the
> >destination is always a VARIANT, VBScript could set the VT to that
> >identified in the TypeInfo for the method about to be called.  The pointer
> >to the corresponding VARIANT union member would then be passed to the
> actual
> >method call.  If the method call fails, the VT could be re-initialized to
> >VT_EMPTY.

> >So, how would that make VBScript any more strongly-typed.  I don't see that
> >it would since, after the method call, the script is still using the [out]
> >parameter as a VARIANT.  This wouldn't make it any more difficult for the
> >script programmer, but a whole lot easier for the COM object developers.

> >Has this approach already been considered for the scripting engines?  If
> >not, please consider it for the next generation of scripting engines.



Mon, 17 Jul 2000 03:00:00 GMT  
 Using ATL COM objects with scripting languages

Here, here!!!

This also means that any components that come "off-the-shelf" cannot be used
(even if they support IDispatch/dual interfaces...) since anything more than
a 'toy' will have non-VARIANT [out] params!!!

If nothing else, please document this in the ASP and VC++ documentation (at
least more explicitly...)

Also, none of the ASP samples that I saw using C++ components had any [out]
parameters at all (only [out,retval] BSTR*)
(I assume [out,retval] can be of any OA type, true?)

If some of the examples showed [out] VARIANT* parameters, I would have clued
in much sooner...

Quote:

>While your passing comments on, please add one more company that would like
this
>feature.  As it stands now, we have to decide when we develop an interface
if we
>want that interface to work with VBScript.  Although it's not very hard to
do,
>we do have to be 'VBScript aware' when developing our interfaces.

>Thank you

>Chad Henke
>Gallagher Financial Systems

<snip>


Sun, 30 Jul 2000 03:00:00 GMT  
 Using ATL COM objects with scripting languages

Quote:

>Here, here!!!

>This also means that any components that come "off-the-shelf" cannot be
used
>(even if they support IDispatch/dual interfaces...) since anything more
than
>a 'toy' will have non-VARIANT [out] params!!!

I don't understand what you mean. IDispatch uses VARIANTs for all of its
arguments, so if you support IDispatch, you support VBScript. What VBScript
won't do is use the dual interface.

Andrew



Sun, 30 Jul 2000 03:00:00 GMT  
 
 [ 15 post ] 

 Relevant Pages 

1. Handling events fired from an ATL COM object in VBScript

2. A WSH that uses Object Rexx as its scripting language

3. Bitmap in VB -> ATL COM object

4. ATL COM Object

5. RFH (Newbie): Objects with ATL COM-server / VBE-client (EXCEL97)

6. passing com/atl object in vb

7. Bitmap in VB -> ATL COM object

8. ATL COM object in VB w/DAO runs out of Stack Space

9. Accessing ATL COM object from V.S. 2003 Embedded VB.NET app

10. Arrays from ATL COM object

11. Problem about using ATL COM in VB.

12. Using Script Host in a COM Object

 

 
Powered by phpBB® Forum Software