Ask a Question related to ASP Components, Design and Development.
-
Miguel Guerreiro #1
How to wrap DLL to make it usable in ASP
I am experiencing a problem that is common for hundreds of ASP
programmers and hopefully we'll be able to solve it here for
everybody.
General Problem: Type mismatch when you pass parameters from ASP to a
VB Component.
Specific Problem: I am using a DLL (3rd party) in VB and I use the
same DLL in ASP on all its properties and methods except one (the most
important one) because this specific method (X.getTextVar()) has 1
argument that returns a pointer to a BSTR type instead of a Variant,
so it occurred to me that I could make a wrapper ActiveX Component for
this DLL in which I would change the problematic method to return
Variants instead of BSTR. The original DLL was written in VC++ and
compiled to be used in VB programs. Is it possible to do what I want
to do? How do I go about doing it? I've never created a DLL wrapper
before.
The proposed solutions should address the sequence of steps on making
the wrapper and modifying the X.getTextVar (Pointer to BSTR) method to
make it get a string and return a Variant. In VBA we can just do "Dim
MyVar As String" and then do X.getTextVar(MyVar). At the end of this
instruction "MyVar" contains a value passed by reference from the
Object "X", but this does not happen in ASP. ASP generates a type
mismatch...simply because the method wants a String and all we can
give it is a Variant. Doing X.getTextVar(CStr(MyVar)) does not end
with a mismatch, but it does not return anything either because the
address that contains the value is never passed out to us, it resides
somewhere in the HEAP.
Documented in Microsoft Knowledge Base articles: 197957, 244012, and
197956.
Description: These knowledge articles talk about this problem as if
the majority of us (ASP programmers) create our own DLL's. The problem
is that there are many 3rd party DLLs that we can successfully use in
Visual Basic for Applications, but that will fail miserably in ASP
just because of the Passing by Reference problem depicted here. On top
of this, Microsoft only shows how to solve the problem if you have the
source code for the DLL, which is not the case when we use 3rd party
DLLs. However, in theory we should be able to create a wrapper that
solves the problem.
This is a hard one, but maybe you can shed some light to hundreds of
us. Thanks for contributing.
Michael G.
Miguel Guerreiro Guest
-
Text wrap adding a ghost Wrap???
hello, I was working on creating a clipping mask on a photo by using the pen tool and making a silo. Then I would cut the picture and paste into... -
cant make text wrap
I started this morning (haha?). and on and off all day I've been coming back into the help files, then ignoring the bloody help files, and still... -
Why would doing a 'Save As' make AI files usable in InDesign?
I just had a problem placing Illustrator files into InDesign. This thread. <http://www.adobeforums.com/cgi-bin/webx?128@@.2ccfc34a> Would someone... -
Can you make list boxes wrap text so information goes onto the next line?
Can you make list boxes wrap text so information goes onto the next line? instead of keep going past the outside of the width of the box. cheers 4... -
Drebin #2
Re: How to wrap DLL to make it usable in ASP
Can't you get that value by using the "set" keyword:
Set bstrRet = x.getTextVar()
instead of
bstrRet = x.getTextVar()
I'm nearly certain that part of COM compliance is that binary strings are
REALLY variant binary strings (like a VT_BSTR) - and if memory serves, that
is going to come back as a byte arry (I *think*?) hth
"Miguel Guerreiro" <mguerreiro@lanefurniture.com> wrote in message
news:71b43864.0308262314.123f0f28@posting.google.c om...> I am experiencing a problem that is common for hundreds of ASP
> programmers and hopefully we'll be able to solve it here for
> everybody.
>
> General Problem: Type mismatch when you pass parameters from ASP to a
> VB Component.
> Specific Problem: I am using a DLL (3rd party) in VB and I use the
> same DLL in ASP on all its properties and methods except one (the most
> important one) because this specific method (X.getTextVar()) has 1
> argument that returns a pointer to a BSTR type instead of a Variant,
> so it occurred to me that I could make a wrapper ActiveX Component for
> this DLL in which I would change the problematic method to return
> Variants instead of BSTR. The original DLL was written in VC++ and
> compiled to be used in VB programs. Is it possible to do what I want
> to do? How do I go about doing it? I've never created a DLL wrapper
> before.
>
> The proposed solutions should address the sequence of steps on making
> the wrapper and modifying the X.getTextVar (Pointer to BSTR) method to
> make it get a string and return a Variant. In VBA we can just do "Dim
> MyVar As String" and then do X.getTextVar(MyVar). At the end of this
> instruction "MyVar" contains a value passed by reference from the
> Object "X", but this does not happen in ASP. ASP generates a type
> mismatch...simply because the method wants a String and all we can
> give it is a Variant. Doing X.getTextVar(CStr(MyVar)) does not end
> with a mismatch, but it does not return anything either because the
> address that contains the value is never passed out to us, it resides
> somewhere in the HEAP.
>
> Documented in Microsoft Knowledge Base articles: 197957, 244012, and
> 197956.
>
> Description: These knowledge articles talk about this problem as if
> the majority of us (ASP programmers) create our own DLL's. The problem
> is that there are many 3rd party DLLs that we can successfully use in
> Visual Basic for Applications, but that will fail miserably in ASP
> just because of the Passing by Reference problem depicted here. On top
> of this, Microsoft only shows how to solve the problem if you have the
> source code for the DLL, which is not the case when we use 3rd party
> DLLs. However, in theory we should be able to create a wrapper that
> solves the problem.
>
> This is a hard one, but maybe you can shed some light to hundreds of
> us. Thanks for contributing.
>
> Michael G.
Drebin Guest



Reply With Quote

