I think, I came to the similar problem as you... I wanted to interact with Netscape browser from another process and nothing helped: objects are created independently as DLLs are loaded independently. Can I draw a conclusion, that XPCOM works in bounds of one process? Marius "Denis" <[EMAIL PROTECTED]> wrote in message 96s7v6$[EMAIL PROTECTED]">news:96s7v6$[EMAIL PROTECTED]... > John, > thanks for your answer. Unfortunately, that's exactly what I was afraid of: > The mechanisms is here (XPCOM and the ServiceManager) but it doesn't seem to > be used fully nor consistantly. > I've tried the plugin newsgroup, checked and rechecked the docs, searched > the code and samples, and debugged/stepped thru the internals of the > ServiceManager (comparing the data (instanciated interface pointers) stored > in its hashtable against pointers of objects used by the browser). Nothing > does it, there does not even appear to be any high level components that I > could a hold of and drill down the hierarchy to get access to those of > interest to me. > I am going to try the xpfe and embedded newsgroup like you suggest, those > are my last chances before having to hack in the sources... :-( > > - Denis > > "John Bandhauer" <[EMAIL PROTECTED]> wrote in message > [EMAIL PROTECTED]">news:[EMAIL PROTECTED]... > > I don't know much about scrollableviews and the viewmanager and > > all that. I'd think the place to ask about that would be the xpfe > > newsgroup. > > > > The xpcom service manager is just a cache of the services that > > were created through the service manager. Any given component > > might be instantiated in some other way (even if it is used as a > > singleton by other code) and not use the same instance as the one > > you might get from the servicemanager. xpcom does not yet have a > > good way to declare which components even *should* be singletons > > and/or instantiated via the servicemanager. > > > > I'd expect that views would be independent and that you'd either > > have to surf from some interface available to the plugin api > > directly or get a very high level interface and drill down until > > you find your window. But, the fact is that I don't know. > > > > I'd suggest digging more in the code and docs (such as they are). > > Maybe http://www.mozilla.org/xpfe/ > > Maybe ask in the xpfe, plugin, and embedding groups. > > Maybe dig deeper into the embedding samples to see how that part > > of the architecture works and what you might be able to get at > > from a plugin. But, note that the frozen parts are few and if you > > use "whatever you can find" then you are using internals that are > > subject to change. > > > > Hope this helps. If I'd known the real answer to your question > > I'd have replied quicker :) > > > > John. > > > > Denis wrote: > > > > > > Hi, > > > the Moz. plugin that I'm working on needs to know what the current > > > scrollbars positions are, and I figured one way of doing this (is there > an > > > easier way?) would be to get access to an instance of one of the classes > in > > > Mozilla that I know have some knowledge about the scrollbars. > > > In simpler terms, I want my plugin to have access to the instance of the > > > ScrollableView interface that the browser is already using. > > > My understanding of XPCOM is that making a call to: > > > nsIServiceManager::GetService(..nsIScrollableView::GetIID()...) > > > should return to me either a new instance of the ScrollableView > interface if > > > none were already registered, or an already existing one if it was > > > registered. It appears however that I am always getting a new instance, > as > > > opposed to the one that the browser is already using. > > > > > > I've tried saving the ServiceManager (say sm) that is passed to the > > > NSRegisterSelf function (these are needed in a plugin to allow it to > self > > > register I believe), and later on use it as: > > > sm->GetService( ...nsIScrollableView::GetIID()..) > > > but I get the same results: an new instance of a ScrollableView, as > opposed > > > to the one that the browser is already using. > > > > > > Most of the documentation and samples that I looked at usually talk > about > > > extending Mozilla in one direction: how to write a component that > registers > > > its interface and services with the idea that you can later on, from > within > > > Moz. code, call and access these services. But I am interested in doing > > > things in the other direction: write a component that can get access to > the > > > (already instanciated) services of Mozilla... > > > > > > I have a feelling I might not be looking at the problem from the right > > > angle, and that the solution is pretty simple, so I'll take any > suggestion > > > and comments! > > > > > > Denis > > > > > > -------- > > > [EMAIL PROTECTED] > >
