Board index » cppbuilder » Problems calling functions in an ActiveX control.

Problems calling functions in an ActiveX control.

I have created a simple activeX control in VB5 which has an attribute of
type String and a function that takes a String by value. This translates
into type BSTR for both the attribute and function argument. In CPPBuilder3
code I can assign the attribute any type of string (char*, String,
WideString) and the compiler accepts these. However, the function argument
is constrained to type BSTR in order to compile correctly. This does not
surprise me, what does is that calling the function results in an access
violation and yet the attribute assignments work fine. If there an
explanation and solution for this it would be greatly appreciated.

' VB Function declaration
public sub MyFunction(ByVal aString as String)
begin
' Do Nothing
end

// CPPBuilder code
// These all work fine....
myActiveX->Caption = "Title";
myActiveX->Caption = WideString("Title");

// ALL of these result in an access violations...
w_char* buf[255];
myActiveX->MyFunction(WideString("Argument"));
myActiveX->MyFunction(WideString("Argument").Detach());
myActiveX->MyFunction(String("Argument").WideChar(buf,254));
myActiveX->MyFunction((BSTR)String("Argument").c_str());

// More specifically the following function in the auto generated header
file causes the access violation
OLECHECK(m_OCXIntf->MyFunction(aArg/*[in]*/));

Wes Hatley
Enabling Technology, Inc.

 

Re:Problems calling functions in an ActiveX control.


: "Wes Hatley" <what...@enabletech.com> wrote:

Quote
>If there an
>explanation and solution for this it would be greatly appreciated.

Visual Basic generates some vital information in an apparently
non-standard way that is nowhere covered in the Microsoft COM
specifications.

This is from a posting by aphrael:

******************************************

Here's the problem:

activex controls usually present two interfaces, a vtable interface which
is determinable via a type library, and an automation interface. using the
vtable interface is much faster.

theoretically, activex controls are supposed to lay out their methods
sequentially, so that they are easily addressable. That is, in a typical
ActiveX, QueryInterface is at some address x, and AddRef is at
x+sizeof(pointer), and Release is at x+2*sizeof(pointer), etc.

VB does not always place its methods at the address expected. That is to
say, in a VB-created ActiveX control derived from IUnknown with 2 new
methods, it is not guaranteed that the first method is at
x+3*sizeof(pointer). Our implementation assumes that it is --- as all
of the COM specifications say it _should_ be --- and so blows up, calling
an address that doesn't exist.

VC was actually broken by this for a while, as well. We are _very_ aware
of the problem, and are working to fix it --- but all of our code that
assumes sequential implementation of functions accessed via a vtable
interface has to be rewritten.

As a workaround, if you go through automation, instead of vtable
interface, it will work.

--
Stefan Hoffmeister (TeamB)     http://www.econos.de/
Please do apply judgement when sending email.

Re:Problems calling functions in an ActiveX control.


Using this advice I replaced the following code

    myActiveX->MyFunction(WideString("Argument"));

with

    Variant v = myActiveX->OleObject;
    v.OleFunction("MyFunction",WideString("Argument"));

and it worked perfectly. Thank you for the prompt and very helpful
information!

Quote
Stefan Hoffmeister (TeamB) wrote in message

<3734fac0.39865...@forums.inprise.com>...
Quote
>: "Wes Hatley" <what...@enabletech.com> wrote:

>>If there an
>>explanation and solution for this it would be greatly appreciated.

>Visual Basic generates some vital information in an apparently
>non-standard way that is nowhere covered in the Microsoft COM
>specifications.
>....

Re:Problems calling functions in an ActiveX control.


You cannot just cast to a bstr.
BSTR is actually a system string.
See SysAllocString et al...
more...
http://tips.kbcafe.com/tips/kb.cgi?terms=bstr

In article <7g4qod$j...@forums.borland.com>,
  "Wes Hatley" <what...@enabletech.com> wrote:

Quote
> I have created a simple activeX control in VB5 which has an attribute of
> type String and a function that takes a String by value. This translates
> into type BSTR for both the attribute and function argument. In CPPBuilder3
> code I can assign the attribute any type of string (char*, String,
> WideString) and the compiler accepts these. However, the function argument
> is constrained to type BSTR in order to compile correctly. This does not
> surprise me, what does is that calling the function results in an access
> violation and yet the attribute assignments work fine. If there an
> explanation and solution for this it would be greatly appreciated.

> ' VB Function declaration
> public sub MyFunction(ByVal aString as String)
> begin
> ' Do Nothing
> end

> // CPPBuilder code
> // These all work fine....
> myActiveX->Caption = "Title";
> myActiveX->Caption = WideString("Title");

> // ALL of these result in an access violations...
> w_char* buf[255];
> myActiveX->MyFunction(WideString("Argument"));
> myActiveX->MyFunction(WideString("Argument").Detach());
> myActiveX->MyFunction(String("Argument").WideChar(buf,254));
> myActiveX->MyFunction((BSTR)String("Argument").c_str());

> // More specifically the following function in the auto generated header
> file causes the access violation
> OLECHECK(m_OCXIntf->MyFunction(aArg/*[in]*/));

> Wes Hatley
> Enabling Technology, Inc.

--
////////////////////////////////////////
// He went out of his way to be good. //
////////////////////////////////////////

-----------== Posted via Deja News, The Discussion Network ==----------
http://www.dejanews.com/       Search, Read, Discuss, or Start Your Own    

Re:Problems calling functions in an ActiveX control.


Wes:

Thanks for posting your solution. I've spent about 6 hours trying to
solve this problem with no luck, even after reading aphrael's
explanation.

Using your code example, the problem was solved in minutes. Thanks
again!

Quote
Wes Hatley wrote:
> Using this advice I replaced the following code

>     myActiveX->MyFunction(WideString("Argument"));

> with

>     Variant v = myActiveX->OleObject;
>     v.OleFunction("MyFunction",WideString("Argument"));

> and it worked perfectly. Thank you for the prompt and very helpful
> information!

> Stefan Hoffmeister (TeamB) wrote in message
> <3734fac0.39865...@forums.inprise.com>...
> >: "Wes Hatley" <what...@enabletech.com> wrote:

> >>If there an
> >>explanation and solution for this it would be greatly appreciated.

> >Visual Basic generates some vital information in an apparently
> >non-standard way that is nowhere covered in the Microsoft COM
> >specifications.
> >....

Other Threads