Board index » delphi » Are BSTR * in parameters ok?

Are BSTR * in parameters ok?

Hi,

  I need to get a string that has lots of data from VB / VBScript into my
COM object. I'm using a BSTR * in parameter for this. It works fine from my
delphi test container. I was wondering if anyone forsaw any problems in
using this under VB / VBS?

  One of the reasons I ask is because it is not in the TLB's drop-down list
(D5) I mean BSTR is, but I had to add the * manually.

--
Chris.

 

Re:Are BSTR * in parameters ok?


I'm always using this, and this working fine with asp (vbscript and
javascript)

Quote
"Chris Jaboc" <n...@no.spam.com> wrote in message news:3bcdd16a_1@dnews...
> Hi,

>   I need to get a string that has lots of data from VB / VBScript into my
> COM object. I'm using a BSTR * in parameter for this. It works fine from
my
> delphi test container. I was wondering if anyone forsaw any problems in
> using this under VB / VBS?

>   One of the reasons I ask is because it is not in the TLB's drop-down
list
> (D5) I mean BSTR is, but I had to add the * manually.

> --
> Chris.

Re:Are BSTR * in parameters ok?


This will unlikely work in VBScript. If you need to create a var/byref
parameter that is usable in VBScript, always use this:

[in, out] VARIANT *param

--
have fun
Binh Ly
http://www.techvanguards.com

Quote
"Chris Jaboc" <n...@no.spam.com> wrote in message news:3bcdd16a_1@dnews...
> Hi,

>   I need to get a string that has lots of data from VB / VBScript into my
> COM object. I'm using a BSTR * in parameter for this. It works fine from
my
> delphi test container. I was wondering if anyone forsaw any problems in
> using this under VB / VBS?

>   One of the reasons I ask is because it is not in the TLB's drop-down
list
> (D5) I mean BSTR is, but I had to add the * manually.

> --
> Chris.

Re:Are BSTR * in parameters ok?


ByRef parameters work just fine in VBScript, JavaScript however won't be able to
change this parameter.

Dmitry Streblechenko (MVP)
http://www.dimastr.com/
OutlookSpy  - Outlook, CDO
and MAPI Developer Tool

Quote
"Binh Ly" <b...@castle.net> wrote in message news:3bcdf5e8$1_1@dnews...
> This will unlikely work in VBScript. If you need to create a var/byref
> parameter that is usable in VBScript, always use this:

> [in, out] VARIANT *param

> --
> have fun
> Binh Ly
> http://www.techvanguards.com

> "Chris Jaboc" <n...@no.spam.com> wrote in message news:3bcdd16a_1@dnews...
> > Hi,

> >   I need to get a string that has lots of data from VB / VBScript into my
> > COM object. I'm using a BSTR * in parameter for this. It works fine from
> my
> > delphi test container. I was wondering if anyone forsaw any problems in
> > using this under VB / VBS?

> >   One of the reasons I ask is because it is not in the TLB's drop-down
> list
> > (D5) I mean BSTR is, but I had to add the * manually.

> > --
> > Chris.

Re:Are BSTR * in parameters ok?


A scripting engine will generally work with ByRef COM parameters only if the
parameter type is *VARIANT*. BSTRs (or any other data type) will generally
not work as ByRef, which was the original question.

Early bound clients, however, will work with any ByRef parameter data type.

--
have fun
Binh Ly
http://www.techvanguards.com

Quote
"Dmitry Streblechenko" <dmi...@dimastr.com> wrote in message

news:3bce105e$1_2@dnews...
Quote
> ByRef parameters work just fine in VBScript, JavaScript however won't be
able to
> change this parameter.

Re:Are BSTR * in parameters ok?


I have to disagree: all IDispatch'able methods still use OleVariants. On the
IDispatch.Invoke() level the parameters are still passed as OleVariants. In case
of BSTR* it will be a variant of type string passed by reference. In Delphi
terms it will be tagVariant.pbstrVal as opposed to tagVariant.bstrVal (note the
"p" prefix).

Dmitry Streblechenko (MVP)
http://www.dimastr.com/
OutlookSpy  - Outlook, CDO
and MAPI Developer Tool

Quote
"Binh Ly" <b...@castle.net> wrote in message news:3bce2e6c_1@dnews...
> A scripting engine will generally work with ByRef COM parameters only if the
> parameter type is *VARIANT*. BSTRs (or any other data type) will generally
> not work as ByRef, which was the original question.

> Early bound clients, however, will work with any ByRef parameter data type.

> --
> have fun
> Binh Ly
> http://www.techvanguards.com

> "Dmitry Streblechenko" <dmi...@dimastr.com> wrote in message
> news:3bce105e$1_2@dnews...
> > ByRef parameters work just fine in VBScript, JavaScript however won't be
> able to
> > change this parameter.

Re:Are BSTR * in parameters ok?


I take it back, you are right: late bound clients always pass variables by
value, not by reference.

Dmitry Streblechenko (MVP)
http://www.dimastr.com/
OutlookSpy  - Outlook, CDO
and MAPI Developer Tool

Quote
"Dmitry Streblechenko" <dmi...@dimastr.com> wrote in message

news:3bce5c58$1_2@dnews...
Quote
> I have to disagree: all IDispatch'able methods still use OleVariants. On the
> IDispatch.Invoke() level the parameters are still passed as OleVariants. In
case
> of BSTR* it will be a variant of type string passed by reference. In Delphi
> terms it will be tagVariant.pbstrVal as opposed to tagVariant.bstrVal (note
the
> "p" prefix).

> Dmitry Streblechenko (MVP)
> http://www.dimastr.com/
> OutlookSpy  - Outlook, CDO
> and MAPI Developer Tool

> "Binh Ly" <b...@castle.net> wrote in message news:3bce2e6c_1@dnews...
> > A scripting engine will generally work with ByRef COM parameters only if the
> > parameter type is *VARIANT*. BSTRs (or any other data type) will generally
> > not work as ByRef, which was the original question.

> > Early bound clients, however, will work with any ByRef parameter data type.

> > --
> > have fun
> > Binh Ly
> > http://www.techvanguards.com

> > "Dmitry Streblechenko" <dmi...@dimastr.com> wrote in message
> > news:3bce105e$1_2@dnews...
> > > ByRef parameters work just fine in VBScript, JavaScript however won't be
> > able to
> > > change this parameter.

Re:Are BSTR * in parameters ok?


Quote
> I take it back, you are right: late bound clients always pass variables
> by value, not by reference.

Now I'm getting confused :-)

If I have a very long string in VBScript / ASP and I would like to pass it
my COM object then:

1) Will VARIANT * duplicate the entire string? Or just point to it?
2) If it copies the whole string, then can I just use a regular BSTR?

--
Chris

Re:Are BSTR * in parameters ok?


1. Yes, it will duplicate it
2. Yes.

Dmitry Streblechenko (MVP)
http://www.dimastr.com/
OutlookSpy  - Outlook, CDO
and MAPI Developer Tool

Quote
"Chris Jaboc" <n...@no.spam.com> wrote in message news:3bcf0173_1@dnews...
> > I take it back, you are right: late bound clients always pass variables
> > by value, not by reference.

> Now I'm getting confused :-)

> If I have a very long string in VBScript / ASP and I would like to pass it
> my COM object then:

> 1) Will VARIANT * duplicate the entire string? Or just point to it?
> 2) If it copies the whole string, then can I just use a regular BSTR?

> --
> Chris

Re:Are BSTR * in parameters ok?


I think we are getting confused here. If you have ASP code that does this:

dim foo
set foo = Server.CreateObject ("FooServer.Foo")
foo.HeresTheString S

This prototype of Foo will work:

HRESULT stdcall IFoo.HeresTheString ([in] BSTR S);

I think this is what you want. At first I thought you needed to do something
with byref parameters but it appears that you don't. Therefore there's no
need to go BSTR* or VARIANT*.

--
have fun
Binh Ly
http://www.techvanguards.com

Quote
"Chris Jaboc" <n...@no.spam.com> wrote in message news:3bcf0173_1@dnews...
> If I have a very long string in VBScript / ASP and I would like to pass it
> my COM object then:

> 1) Will VARIANT * duplicate the entire string? Or just point to it?
> 2) If it copies the whole string, then can I just use a regular BSTR?

Re:Are BSTR * in parameters ok?


I need to put another twist on it though. My COM object will also run in a
VB environment without the special ASP stuff, therefore it will not always
run under VBScript / JScript.

My understanding from your posts is that under VB, a BSTR can be passed
byref? (which I use in my code as a PWideChar).

The benefit here is that since the string being passed could be extremely
long then I would like to access it by pointer if possible.

My understanding now is that:

1) Under VB this is no problem

2) Under VBScript / JScript, it will be copied as a regular BSTR but my
pwidechar should still work from inside my delphi code because it would just
be pointing to the new BSTR.

3) Therefore it is ok to use BSTR* and it will actually pass byref
sometimes, but (and this is the major thing that needs verification) using a
BSTR * won't crash my COM object or the container using VB / VBScript /
JScript or whatnot. I'm using it like this in a Delphi container right now
and it is working fine ( I mean I'm calling the Delphi COM object from a
Delphi APP)

Quote
> HRESULT stdcall IFoo.HeresTheString ([in] BSTR S);

> I think this is what you want. At first I thought you needed to do
> something with byref parameters but it appears that you don't.
> Therefore there's no need to go BSTR* or VARIANT*.

--
Chris.

Re:Are BSTR * in parameters ok?


You can also have
HRESULT stdcall IFoo.HeresTheString ([in, out] BSTR * S);
but when calling from VBS or JS,
foo.HeresTheString S
S will *not* be changed even if HeresTheString() does change it.
If you use early binding in VB, HeresTheString() can modify the string and the
change will be propagated back to the caller.

Dmitry Streblechenko (MVP)
http://www.dimastr.com/
OutlookSpy  - Outlook, CDO
and MAPI Developer Tool

Quote
"Binh Ly" <b...@castle.net> wrote in message news:3bcf4ad6_1@dnews...
> I think we are getting confused here. If you have ASP code that does this:

> dim foo
> set foo = Server.CreateObject ("FooServer.Foo")
> foo.HeresTheString S

> This prototype of Foo will work:

> HRESULT stdcall IFoo.HeresTheString ([in] BSTR S);

> I think this is what you want. At first I thought you needed to do something
> with byref parameters but it appears that you don't. Therefore there's no
> need to go BSTR* or VARIANT*.

> --
> have fun
> Binh Ly
> http://www.techvanguards.com

> "Chris Jaboc" <n...@no.spam.com> wrote in message news:3bcf0173_1@dnews...
> > If I have a very long string in VBScript / ASP and I would like to pass it
> > my COM object then:

> > 1) Will VARIANT * duplicate the entire string? Or just point to it?
> > 2) If it copies the whole string, then can I just use a regular BSTR?

Re:Are BSTR * in parameters ok?


Ok now I understand what you're getting at here.

You want [in] BSTR* for efficiency. No this will not likely work in a script
environment.
If you change it slightly to [in, out] BSTR*, it will not likely work in a
script environment.

I am refering to ASP here. It is possible that other scripting environments
might accept this but I would not count on it. Therefore, you want: [in]
BSTR. This will likely work in any script environment.

--
have fun
Binh Ly
http://www.techvanguards.com

Quote
"Chris Jaboc" <n...@no.spam.com> wrote in message news:3bcf6185$1_1@dnews...
> I need to put another twist on it though. My COM object will also run in a
> VB environment without the special ASP stuff, therefore it will not always
> run under VBScript / JScript.

> My understanding from your posts is that under VB, a BSTR can be passed
> byref? (which I use in my code as a PWideChar).

> The benefit here is that since the string being passed could be extremely
> long then I would like to access it by pointer if possible.

> My understanding now is that:

> 1) Under VB this is no problem

> 2) Under VBScript / JScript, it will be copied as a regular BSTR but my
> pwidechar should still work from inside my delphi code because it would
just
> be pointing to the new BSTR.

> 3) Therefore it is ok to use BSTR* and it will actually pass byref
> sometimes, but (and this is the major thing that needs verification) using
a
> BSTR * won't crash my COM object or the container using VB / VBScript /
> JScript or whatnot. I'm using it like this in a Delphi container right now
> and it is working fine ( I mean I'm calling the Delphi COM object from a
> Delphi APP)

Other Threads