String issues and embedding w/1.7

Kevin Ollivier <[email protected]> Wed, 14 Jul 2004 21:07:31 -0700
Newsgroups gmane.comp.mozilla.devel.embedding,gmane.comp.mozilla.devel.xpcom
Message-ID <[email protected]>
Hi all,

I recently attempted to move wxMozilla up to 1.7 as I think it's a good 
thing to do considering it's the new stable branch. ;-) Unfortunately, 
I have so far not been able to move wxMozilla over to 1.7 successfully. 
I thought I would explain what bumps I've run into and see if these are 
problems with what I've done, or are indeed Mozilla glitches.

wxMozilla has used the internal string APIs up until now, mostly out of 
necessity, although part of it was also that things "just worked" and 
we didn't know exactly how much work a move to embedString would be. 
After reading about the string changes in 1.7, I attempted a move to 
the embedString string libraries, but the problem is that there are 
non-frozen interfaces which include/use the internal string APIs still, 
and AFAIK in 1.7 one cannot use both embedString and the internal 
string APIs together, because nsStringAPI.h and nsString.h have 
different definitions of the same classes. Here are the non-frozen APIs 
that are causing conflicts:

- nsIWebBrowserPersist - obviously, this is very important for save 
functionality

- nsIDocument - we need this for our GetPage() routine that returns the 
page source as a string.

- nsIChromeEventHandler, nsPIDOMWindow, nsIDOMWindowInternal, 
nsIChromeEventHandler - these are all needed to get an 
nsIDOMEventReceiver, which we need in order to to add listeners for 
keyboard and mouse events. IMHO, adding a method accessible using 
nsWebBrowser, like GetEventReceiver, would make this a lot simpler and 
keep the internal classes internal.

I'm not sure if there are other dependencies lurking around in the 
source somewhere, but I think these are the important ones. Any advice 
on what I could do to resolve these issues would be appreciated!

Thanks,

Kevin