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
