Return object to JavaScript from C++

[ke...@endurasoft.com]

Hello, and thanks for reading...

I have a C++-based plugin that interracts with SpiderMonkey. I've
implemented callbacks (working), but they're currently being called
back with intrinsic data types. I'd much rather create a structure and
return that to the JavaScript callback. For example:

function Page_Load()
{
...
myPlugin.AttachErrorHandler(MyErrorHandler);
...
}

// Working today:
function MyErrorHandler(errorCode, errorMessage)
{
alert('The error message was: ' + errorMessage);
}

// Desired:
function MyErrorHandler(errorInfo)
{
alert('The error message was: ' + errorInfo.errorMessage);
}

The C++-based plugin implements the "AttachErrorHandler" method and
performs the callback to the "MyErrorHandler" method when necessary.
This is essentially working without the returned structure (returning
integers and strings instead).

To return an object, I've created XPIDL that identifies the
"errorInfo" object (derived from nsISupports), and I pass that into
the XPIDL definition for the error handler:

[scriptable, uuid(...)]
interface IMyExceptionInfo : nsISupports
{
readonly attribute long errorCode;
readonly attribute wstring errorMessage; // wstring since we're
binding to a Win32 DLL for information
};
...
[scriptable, function, uuid(...)]
interface IMyExceptionCallback : nsISupports
{
boolean onError(in IMyExceptionInfo errorInfo);
};

This compiles nicely. However, when I move this into C++, using the
header XPIDL creates, when it's time to toss an error object back to
the JavaScript, I get a compilation error (PR_GetCurrentThread isn't
linked in). This is the code:

(In my own header file)
class MyExceptionInfo : public IMyExceptionInfo
{
public:
NS_DECL_ISUPPORTS
NS_DECL_IMYEXCEPTIONINFO

MyExceptionInfo();
~MyExceptionInfo();

protected:
/* additional members */
};

(In the C++ method that creates the exception information object):
PRBool ok;
MyExceptionInfo ex;
MyPluginClass::onException->OnError(&ex, &ok); // static since it's a
callback

I have my doubts as to whether this is the proper way to create the
object for return, which is why I've turned to this group for any
insight. The returned object is, of course, an XPCOM object, so
creating an instance on the stack may not be the best approach. But
being rather new to XPCOM in general, I had no other information to
work with. Many searches haven't turned up what I need.

Any insight? Many thanks in advance...

[ke...@endurasoft.com]

> I have my doubts as to whether this is the proper way to create the
> object for return, which is why I've turned to this group for any
> insight. The returned object is, of course, an XPCOM object, so
> creating an instance on the stack may not be the best approach.

In case anyone actually did wonder... :)

I tried making the objects components and registered them with XPCOM
so I could use do_CreateInstance. But that kept failing even though
that's probably the right way to do it. Perhaps some small coding
error kept it from working? Anyway, I discovered that if I linked to
nspr4.lib I could get past my PR_GetCurrentThread link error. Then I
created an instance of the object using new, applied a static cast,
and it worked:

MyExceptionInfo* exi = new MyExceptionInfo();
nsCOMPtr<IMyExceptionInfo> pExi = NS_STATIC_CAST(IMyExceptionInfo *,
exi); // return pExi to callback fn

Of course, I now have other issues, but I'm past this one. String
issues (oh well...I'm sure learning a lot). Thanks for reading...

[ke...@endurasoft.com]

> Of course, I now have other issues, but I'm past this one. String
> issues (oh well...I'm sure learning a lot).

As a final note, the string issue I was having turned out not to be a
string issue but rather a security issue. My object didn't implement
nsIClassInfo. Once I provided an implementation for this interface,
the object worked in JavaScript wonderfully. In case it helps
anyone...