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