Hi, Thanks Gangadhar for the reply - I think I've at least figured out my build problems but I'll have a look at your suggestion also. W.r.t using unfrozen code. Do you know if there is a frozen alternative to using ContentPolicy ShouldLoad()? Also, I'm still having a problem registering and executing my component which I've described below - Any suggestions would be a great help. I've included the details on what I've done to fix the linking problem I was having in case it's of any help to anyone.
--- fix for my linking problems --- Basically I'm using the following version of the SDK gecko-sdk-i586-pc-msvc-1.7.3.zip which I got from http://ftp.mozilla.org/pub/mozilla.org/mozilla/releases/. I'm also using the latest nsIContentPolicy.idl that I got from here http://lxr.mozilla.org/mozilla/source/content/base/public/ 1)Using xpidl.exe compile nsIContentPolicy to generate its header. Include this header in you build. 2)The instructions in the "Creating XPCOM Components" component book seem to be out of date (although I must say the tutorial itself is very good). All you need to link against is xpcom.lib (comes in gecko-sdk-i586-pc-msvc-1.7.3.zip) - (as Gangadhar suggests it may be better to link against xpcomglue.lib rather than xpcom.lib - I haven't tried this yet). 3)The nsIContentPolicy header defines two pure virtual functions you need to implement in your own code, ShouldLoad() and ShouldProcess(). ShouldLoad is the one I'm interested in as it's called before a page is rendered and gives you access to URL info. 4)Implement these functions in your code. 5) You still need to do the code steps described in "Creating XPCOM Components" (see http://www.mozilla.org/projects/xpcom/book/cxc/html/newbookTOC.html) to register your component and have it loaded when XPCOM starts. --- PROBLEM REGISTERING AND RUNNING MY XPCOM COMPONENT --- However!!! - I'm still having problems. I register my component using regxpcom as instructed, but for some reason it doesn't seem to be working. In fact even though regxpcom says that it's registered sucessfully I'm not sure it is. When I use component viewer in Mozilla, my component doesn't appear in the list of registered components. Anyone got any ideas why it doesn't appear? I use regxpcom as follows; regxpcom -x "C:\Program Files\Common Files\mozilla.org\GRE\1.7.6_2005031907" "C:\Program Files\Common Files\mozilla.org\GRE\1.7.6_2005031907\components\TestPageLoad.dll" Am I putting my dll in the right place? If I take a look at compreg.dat I can see it's been updated with details of my component and the interfaces my component is accessing. But as I say my code doesn't seem to be getting called and I can't see my component in component viewer. Any help greatly appreciated. Thanks, Damo -----Original Message----- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Gangadhar NPK Sent: 04 April 2005 20:13 To: [email protected] Subject: Re: nsIContentPolicy interface, ShouldLoad link problem 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 _______________________________________________ Mozilla-xpcom mailing list [email protected] http://mail.mozilla.org/listinfo/mozilla-xpcom
