ASPN ActiveState Programmer Network
ActiveState
/ Home / Perl / PHP / Python / Tcl / XSLT /
/ Safari / My ASPN /
Cookbooks | Documentation | Mailing Lists | Modules | News Feeds | Products | User Groups


Recent Messages
List Archives
About the List
List Leaders
Subscription Options

View Subscriptions
Help

View by Topic
ActiveState
.NET Framework
Open Source
Perl
PHP
Python
Tcl
Web Services
XML & XSLT

View by Category
Database
General
SOAP
System Administration
Tools
User Interfaces
Web Programming
XML Programming


MyASPN >> Mail Archive >> pyxpcom
pyxpcom
Re: [pyxpcom] Problems with getService
by Stefan Farestam other posts by this author
Aug 16 2005 10:59PM messages near this date
view in the new Beta List Site
RE: [pyxpcom] Problems with getService | RE: [pyxpcom] Problems with getService
Mark Hammond wrote the following on 08/16/2005 10:19 PM:
> >I just compiled the latest version of pyxpcom on windows. When
> >testing it I found that using pyxpcom through mozilla worked
> >fine, but when called independently through either regxpcom
> >or by invoking python it generated an error. I isolated the problem
> >to being able to create a service. In particular, the following
> >piece used to work fine, but now generates an error:
>  
>  
>  The problem may be the lack of an XPCOM registry in the directory pyxpcom
>  uses.  When it initializes XPCOM, it assumes the directory of nspr4.dll (or
>  possibly a different one depending on the patch version) is the xpcom system
>  dir.  I suspect that in some build configurations this is not true.  When
>  run from Mozilla, Mozilla has already initialized xpcom, so this code is not
>  hit.

Ok. In my case nspr4.dll is located in the mozilla library directory.
The "components" directory, with xpti.dat and compreg.dat, is a subdirectory
of the the mozilla library directory.

I tried moving nspr4.dll to the "components" directory but got the same
behavior (and yes, I had to add "components" to the path in order for
the dll to be found).

>  You could try hacking the code to print the xpcom directory Python is using,
>  and checking that it is incorrect.

Are you saying that I need to hack the source code for pyxpcom to do this?
If so where?

>  If so, then hard-code in the correct
>  directory and see if it works.  If it does, we need to work out a better way
>  than the hard-coding :)

Would be nice to avoid hardcoding since I would like to be able to
move around the install between machines without recompiling.

What mystifies me is that I haven't really changed much from the build
procedure that I used 8 months ago, but now the behavior is different.

Is there anything in my build setup that possibly could have provoked
the new behavior?

By the way, my work-around is to remove compreg.dat and start mozilla
which then performs an auto-registration of components.
_______________________________________________
pyxpcom mailing list
pyxpcom@[...].com
To unsubscribe: http://listserv.ActiveState.com/mailman/mysubs
Thread:
Stefan Farestam
Mark Hammond
Stefan Farestam
Mark Hammond
Stefan Farestam

Privacy Policy | Email Opt-out | Feedback | Syndication
© ActiveState Software Inc. All rights reserved