Ari Heitner wrote:
>
> On Thu, 28 Dec 2000, Michael Ang wrote:
>
> > Ari Heitner wrote:
>
> > Check out the XPConnect docs at http://www.mozilla.org/scriptable/.
> > Particularly the "Components" object reference at
> > http://www.mozilla.org/scriptable/components_object.html.
>
> natch. beautiful.
>
> >
> > All your answers lie in the archives of newsgroup
> > netscape.public.mozilla.xpcom. All the articles are kept on news host
> > news.mozilla.org, or you can use a search engine like
> > www.deja.com/usenet to search the archives.
> >
> > > 2) i actually have a somewhat related problem: i need to get XPCOM (well, the
> > > nsComponentManager i guess) to load typelib files dynamically (the reasons why
> > > are a long story; suffice to say i'm an embedding application and don't have
> > > access to the mozilla install dir). you all wouldn't know anything about that,
> > > would you?
> >
> > I'm pretty sure this has been answered on n.p.m.xpcom before, but I
> > forget what the answer is.
>
> just spent the morning reading *all* of n.p.m.xpcom, '98 to the present :)
> (okay, not every message. but every thread that looked moderately relevant).
> it was a very informative experience (jband: "someday we hope to have a way to
> allow people to use XPConnect from JS without modifying their prefs.js to hack
> the security settings...").
>
> the question that always gets asked is "why do *my* interfaces not show up in
> components.interfaces, but components.interfaces.nsISupports is always there",
> and jband's answer is always "just put it in components/, and make sure to kill
> xpti.dat if you're running a Release build". Which is exactly what he told me
> when I asked this about a week ago (i seriously hope he's got a perl script
> that can auto-reply his top-10 helpful posts...)
For this purpose, the distinction between debug and release
builds is whether or not 'DEBUG' is defined when the C
preprocessor runs.
>
> and my problem is still the same: i need XPCOM to see typelib's even if they're
> not in components/, since i don't have access to that directory. I'd be happy
> to point XPCOM to where my xpt's *are* (or write the code needed to do that, if
> someone can point me where it should live). dmose theorized that XPCOM might
> look wherever the library file is, which suggests the slightly hackish (imho)
> tack of doing something like a nsComponentManager::RegisterComponentLib, which
> might cause XPCOM to look wherever the .so is for the .xpt. Except that the
> docs on this function read:
>
> /**
> * registerComponentLib
> *
> * Register a native dll module via its dll name (not full path) as the
> * container of CID implemenation aClass and associate aContractID and
> * aClassName
> [...]
>
> which makes me think XPCOM is only smart enough to look in components/ in the
> first place.
xpcom is built of multiple subsystems. You are pointing out a
method of the component manager. The part of interest here is the
Type Info Loader (xpti). The current mozilla-the-browser really
only needed to load xpt files from one place. So that is what the
current code does. It was not completely clear to me whether or
not you are doing your own embedding of xpcom (where you can
build your own version of the binaries) or you are instead
building a system that relies on users having binaries from other
vendors. If you have control of the binaries and having xpt files
come from only one directory (but not the current place) is OK
with you then you can reimplement:
xptiInterfaceInfoManager::GetComponentsDir
and
xptiInterfaceInfoManager::GetManifestDir
at
http://lxr.mozilla.org/seamonkey/source/xpcom/reflect/xptinfo/src/xptiInterfaceInfoManager.cpp#162
GetComponentsDir is the place where xpti will find and load xpt
files.
GetManifestDir is the place where xpti will read and write
xpti.dat.
Both of these methods need to build and return a new object
implementing nsILocalFile each time they are called.
If you reimplement these methods to point elsewhere and copy all
the existing xpt files to that new place then it should just
work.
An alternative to the above is to leave that code alone and
instead change your copy of the implementation of
"GetDirectoryFromDirService(NS_XPCOM_COMPONENT_DIR, aDir);". I
*think* that would change where xpti finds xpt files *and* where
the native component loader find .dll files too. I'm not sure if
you want that or not.
If you really need to have the xpti system find xpt files in
various places then there is a much larger problem. This would
require larger structural changes to xpti. This would require the
concept of a search path, a more complicated file search scheme,
and another level in the internal hierarchy to describe the
directory in which a given xpt file was found. I'm in no rush to
do that if it is not *really* needed.
John.
>
> So yeah. Maybe the whole situation is rather narrow minded. But it seems it
> should be easy to fix, if that's what's needed.
>
> Caveat mozillahackers: I will only promise to write this if someone tells me
> what to write in the next few days. My magic window of time only goes 1 1/2
> weeks into january ...
>
> > > pps i seriously suggest you just ignore me, because if you respond i'll just
> > > keep bothering you. you wouldn't want that.
> >
> > I'll take your advice and ignore any more questions you send me
> > directly. ;) *But*, I'd be happy to answer any questions that you ask
> > in the XPCOM newsgroup/mailing list. See
>
> hell, i'll annoy you *and* the list :P
>
> cheers,
>
> ari
