Oops, I failed to mention that the error code I'm getting from NS_NewNativeLocalFile is NS_ERROR_NOT_INITIALIZED.
Thanks again for your time. -- Brad Fish [EMAIL PROTECTED] TALL Group Programmer "Brad Fish" <[EMAIL PROTECTED]> wrote in message news:[EMAIL PROTECTED] > Doug, > > Thanks for the quick reply. I am actually writing a DLL that I'm using to > contain all of my Mozilla embedding code. When I linked with just > embed_base_s.lib and > xpcom.lib, everything worked just fine, provided that my Mozilla > installation was both in my PATH and specified in the call to > NS_InitEmbedding. However, once I removed my Mozilla installation directory > from my PATH and just pointed to the install directory, NS_InitEmbedding > would fail. This led me to investigate xpcomglue. > > Also thanks for having me double check that I was finding the GRE correctly. > Turns out I wasn't. NS_NewNativeLocalFile was actually failing, but I > wasn't catching it do to a synchronization error with another thread. I've > double checked that the directory I'm giving it does indeed exist, and it > contains a straight copy of my Mozilla bin directory and all of its > subdirectories. So, I haven't actually installed a GRE, would that be a > problem for some reason? I don't see how it could be, because it's just as > if I had installed Mozilla in a different directory and am pointing to that > instead of what I was previously handing to NS_InitEmbedding. > > Is there a problem with using NS_NewNativeLocalFile with xpcomglue? > > Like I said, this all worked without problems until I started using > xpcomglue. The only other thing that I can think of is that I also had to > change my compiler switch from /MT to /MD to satisfy the imports for some of > those libraries I linked with, but I don't see how that could be the > problem. I'm really stumped on this one. Thanks again for any help you can > offer. My experience working with Mozilla has been very enjoyable and it > will be even more so when I can get this resolved. > > P.S. -- I found that I had to link to both nspr4_s.lib and nspr4.lib in > order to get my DLL to compile, thus making it dependent on nspr4.dll. Is > this to be expected? I was hoping to not have to be dependent on any DLLs > outside the GRE (which I don't know the location of in advance), but it's > not vital. However, if there is a way to remove the dependency on > nspr4.dll, that would really be swell. Are there any other issues perhaps > related to the libraries I'm linking with? > -- > Brad Fish > [EMAIL PROTECTED] > TALL Group Programmer > "Doug Turner" <[EMAIL PROTECTED]> wrote in message > news:[EMAIL PROTECTED] > > Hi Brad, > > > > How does it fail; what is the return code? Do other calls into service > > manager return anything sucessfully (can you aquire other services)? > > Are you sure that your application did properly find the GRE? > > > > Regards, > > Doug Turner > > > > > > Brad Fish wrote: > > > > > I recently tried linking my application against xpcomglue.lib so that I > > > could point to a GRE at an unknown location. However, once I succeeded > in > > > doing this, a call to do_GetService(NS_XPCOMPROXY_CONTRACTID, &rv) to > get > > > the nsIProxyObjectManager service no longer succeeds. I'm definitely > not a > > > Mozilla expert and really have no idea why this wouldn't be working. I > > > would appreciate it if anyone with some expertise with xpcomglue.lib and > > > GREs could help me on this one. > > > > > > Also, I linked with the following libraries in order to get my code to > link > > > properly, which may have something to do with it: > > > > > > embed_base_s.lib > > > string_obsolete_s.lib > > > string_s.lib > > > plc4_s.lib > > > plds4_s.lib > > > xpcomglue.lib > > > xpcomds_s.lib > > > embedstring_s.lib > > > nspr4.lib > > > nspr4_s.lib > > > nsldif32v50.lib > > > > > > Thanks in advance for any help you can offer. > > > -- > > > Brad Fish > > > [EMAIL PROTECTED] > > > TALL Group Programmer > > > > > > > > > > >
