Hi,
When linking against xpcom, try to link against xpcomglue.lib. That way you will be shielded from (most) of the changes happening inside xpcom.
Coming to your second question - the answer is Yes. As long as you are using an unfrozen api, you have no choice but to ship different versions of your component for the various versions of the browsers. But these days the api changes are fairly less and so the amount of change you need to do in your code might be minimal.
And coming to the file that is missing, let me dig in to the example for weblock and see what I did for this. I have a msvc6 project for this, which I used long back (gecko-1.4 IIRC). Let me dig into it and see what I can find.
hth
Gangadhar


Damien O'Brien wrote:
Hi,
I'm developing my first XPCOM component for Mozilla on windows XP using VS.NET. I want my component to do some work every time the user loads a new web page. I've been following the WebLock tutorial in "Creating XPCOM Components" by Doug Turner and Ian Oeschger. This describes using the ShouldLoad method from the ContentPolicy interface. I understand pretty much how this all works. The main problem I'm having at the moment is simply building my component. The tutorial describes using a particular version of the Gecko SDK (gecko-sdk-win32-1.4.1.zip - I think). With this you get a bunch of libraries and headers which the tutorial says you need (nspr4.lib plds4.lib plc4.lib embedstring.lib xpcomglue.lib). The tutorial also says that you need to get the nsIConentPolicy.idl file and use xpidl to generate nsIContentPolicy.h. I presume you then build your component using the generated header and the libs mentioned above and the other headers that come with the SDK.


My questions:
1) After gecko-sdk-win32-1.4.1.zip the next available zip file containing all the libs specified in the tutorial seems to be 1.6a - there are no others after that (I'm looking in _http://ftp.mozilla.org/pub/mozilla.org/mozilla/releases/_ for these). Can you use more recent SDK zips (e.g. gecko-sdk-i586-pc-msvc-1.7.3.zip) to build a component like this? I'm assuming so, but while the 1.7.3 zip contains nspr4.dll and plc4.dll, etc.., it doesn’t have the libs needed for linking. I tried linking against just xpcom.lib but I got a link error because if couldn't resolve the shouldLoad method (presumably because it doesn't contain the implementation for shouldLoad). Exactly what do I need to compile/link against to get the ShouldLoad method?


Or am I completely off the point here and missing something totally fundamental to building an XPCOM component when using unfrozen .idl's?

2) ShouldLoad and the nsIContentPolicy interface are not frozen. I want my component to work across a number of Gecko based browsers and browser versions. But I see that people have had cross browser problems with shouldLoad due to API changes. I presume these developers have ended up building several different DLLs depending on the browser and browser versions they want their compoent to work with. Is there a better "frozen" way for my component to be informed of page loads rather than using shouldLoad (e.g.onStartURIOpen() - not sure if this is unfrozen also).

Or is the only option to stick with ShouldLoad and have several different builds of my dll and depoly the appropriate one depending on the browser the end user is using?

Thanks,
 Damo

_______________________________________________
Mozilla-xpcom mailing list
[email protected]
http://mail.mozilla.org/listinfo/mozilla-xpcom

Reply via email to