Jon Yurek wrote:

Darin Fisher wrote:


nsAutoString is a private internal string class. Using it in your components means that your components may not be compatible with other versions of Mozilla. You should instead compile your component against the Gecko SDK. For Firefox 1.0 (and Mozilla 1.7) or later, you can use the Gecko SDK that ships with Mozilla 1.7. I'd recommend using the Gecko SDK that shipped with Mozilla 1.7.5:
ftp://ftp.mozilla.org/pub/mozilla.org/mozilla/releases/mozilla1.7.5/gecko-sdk-i586-pc-msvc-1.7.5.zip




I understand this. I was already informed about nsAutoString and was trying to compile with the Gecko SDK. Although I will say that nsAutoString doesn't appear anywhere in my code, so I can only assume it had been included as a result of compiling the component through building Mozilla instead of through the SDK.

But that was only part of my problem. I got the SDK and tried building, only to find that the xmlextras aren't included. Unfortunately, the parser and serializer are required for my component, so their omission from the SDK is a bit troubling. Do I have to go and download the headers from someplace else, or can I just take them from the Firefox source? Would it be a problem if I did this? That is, would I be getting the same invalid entry point errors since they're not part of the standard SDK?


Whenever you need to use unfrozen interfaces, the thing to do is to get a copy of the generated header file out of the source for the Mozilla version that you are targetting. Then, you can include that copy in your local source tree, so that you don't always have to have a complete copy of the Mozilla source tree handy.


Now, when using an unfrozen interface, you need to take extreme care to avoid causing crashes when your code is used with a different version of Mozilla than the one you are testing it against. Be sure to use QueryInterface liberally to ensure that you indeed have a nsIDOMParser instance when you think you should have one. Be sure to check and handle errors since if nsIDOMParser changes in the future, it's UUID property will also change.

It's unfortunate that we have not frozen nsIDOMParser to the corresponding serializer. We really ought to freeze those components!

-Darin
_______________________________________________
Mozilla-xpcom mailing list
[EMAIL PROTECTED]
http://mail.mozilla.org/listinfo/mozilla-xpcom

Reply via email to