And just to see if there was a recursion lock built into XPConnect, I started a timer in the AsynchLookup call and returned immediately. When the timer fired, I tried to do the callback, with the same error code resulting. (Yes, it was on the same thread, my C++ object is now also a window, and I used WM_TIMER.)
-----Original Message----- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Schmidt, Paul Sent: Monday, December 04, 2006 3:45 PM To: [EMAIL PROTECTED]; [email protected] Subject: RE: XPCOM cpp to js callback It's definitely still loaded, I'm doing this in a very simple test page w/o any navigation or anything, and a subsequent JS alert is popping up as expected. My callback function is so far just a placeholder: onLookupComplete: function( aRequest, aResult ) { alert("js: myListener: onLookupComplete(" + aRequest + ", " + aResult ")\n"); } .. so yeah, I *think* I'd know if it got called back. :-) (I just tried wrapping the alert in a try/catch block, and it still didn't get called. I also called the function directly, and I did get the alert.) Thanks for the info on the QI behavior, I've been doing COM for so long I've come to expect things in XPCOM that don't necessarily hold. And to reveal more of my newbie-ness: how do I open the error console in FireFox? Thanks! -Paul -----Original Message----- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of John Bandhauer Sent: Monday, December 04, 2006 3:30 PM To: [email protected] Subject: Re: XPCOM cpp to js callback Are you so sure your callback is not getting called? If your js code is not still the loaded document in some window then it's global object might not still *have* an 'alert' method and *that* might be the cause of the generic failure code. Have you looked in the error console for interesting error info? If XPConnect were having difficulty calling your method then you should expect it to likely return a more interesting nsresult than the generic failure code. Your JS obj is not going to get as many QI calls as you expect. XPConnect will try a QI for nsISupports to establish object identity in some cases. But, inasmuch as JS objects are not even required to implement QI, the fact that your object is not QI'd for your special interface is not telling. XPConnect *trusts* you when you pass the object as an instance of your interface. It builds a wrapper to represent that interface for you and hands it to your C++ code. I'm pretty sure that nsCOMPtr assignment does not require a QI call in the normal case either. It is assigning typed pointers and doing ref counting only. John. _______________________________________________ dev-tech-xpcom mailing list [email protected] https://lists.mozilla.org/listinfo/dev-tech-xpcom _______________________________________________ dev-tech-xpcom mailing list [email protected] https://lists.mozilla.org/listinfo/dev-tech-xpcom _______________________________________________ dev-tech-xpcom mailing list [email protected] https://lists.mozilla.org/listinfo/dev-tech-xpcom
