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 Mark Hammond other posts by this author
Aug 16 2005 11:47PM messages near this date
view in the new Beta List Site
Re: [pyxpcom] Problems with getService | Re: [pyxpcom] Problems with getService
>  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.

That sounds correct so should work.

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

The code I was referring to is in xpcom.cpp, line 529.  The block:

			// On Windows this by using locating a Moz DLL we depend
			// on, and assume it lives in that bin dir.  Different
			// moz build types (eg, xulrunner, suite) package
			// XPCOM itself differently - but all appear to offer
			// nspr4.dll - so this is what we use.
			char landmark[MAX_PATH+1];
			HMODULE hmod = GetModuleHandle("nspr4.dll");
			if (hmod==NULL) {
				PyErr_SetString(PyExc_RuntimeError, "We dont appear to be linked against
nspr4.dll");
				return PR_FALSE;
			}
			GetModuleFileName(hmod, landmark, sizeof(landmark)/sizeof(landmark[0]));

is attempting to locate the xpcom directory - which I believe should be the
directory with compreg.dat.  From what you described, I think you would find
that the directory portion of 'landmark' does point to the correct
directory.

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

Yes, hence I said we need to find a better way :)

>  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.

I was guessing it was Mozilla itself that has moved on.  It sounds like I
may be wrong in this case.  I seem to have successful builds for both the
'xul_runner' and 'suite' projects.

>  By the way, my work-around is to remove compreg.dat and start mozilla
>  which then performs an auto-registration of components.

So once you have done that, stand-alone Python programs using xpcom again
work?  Bizarre...

Mark

_______________________________________________
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