IBMBIDI is impacting non-trailing methods in interfaces? Yuk!
I expect the cdecl vs. stdcall issue you mentioned was a failure
to define XP_PC in Win32 your project, right? I have an #error
patch for nsISupportsUtils.h to help people catch this early on.
The error result code from the failed createInstance call might
supply a good clue. You should see this in the JS console if you
are failing in the call from JS.
If you are working with Win32 you might find it worthwhile to
build a 'release-with-symbols' build. You can do this by
setting...
set MOZ_DEBUG=
set MOZ_PURIFY=1
set MOZ_PROFILE=1
...in your environment before building. It does the same thing as
a release build, but also makes .pdb files so you can debug
through the mozilla code. If you've never debugged though such a
build you might find it interesting. It is similar to a debug
build except that you can't easily inspect some local vars if
they've been optimized into registers (or out of existence!). And
the debugger often gives disinformation when dealing with code
that has been optimized in ways it does not understand.
Debugging into the createInstance code is a pain because it is
called from so many places. You can always hack in some code to
break into the debugger when it is called with some given cid.
Hope this helps.
John.
John Nason wrote:
>
> Yeah, unfortunately I did re-run regxpcom. I'm in the registry and I show up
> in xpti.dat... making sure that they were the correct release versions. I'm
> really hung up on preprocessor definitions, cuz I already ran into a really
> insidious problem where Mozilla debug built with IBMBIDI defined, I didn't
> build my dll with that, and my dll vtable was two entries off what it should
> have been. This and a stupid cdecl vs. stdcal problem have led me to blame
> everything on the damn definitions! I could be completely in left field,
> however.
> Thank you for the input, though.
> -john
> "John Bandhauer" <[EMAIL PROTECTED]> wrote in message
> [EMAIL PROTECTED]">news:[EMAIL PROTECTED]...
> > John Nason wrote:
> > >
> > > Hello,
> > > I'm having a tough problem, windows related... I can do a createInstance
> on
> > > my own component when I use my debug version of Mozilla(.93). It is
> called
> > > from a javascript that is registered in the chrome. When I use my
> Release
> > > version or use Netscape 6.1, my dll does not even get loaded(the script
> does
> > > get executed). There seems to be a difference somewhere with a XPCOM
> > > preprocessor definition or something. I link and include against
> > > win32_o.obj. When I build the release version of my dll(with
> win32_o.obj) I
> > > can still load my dll with the debug version of Mozilla, but not
> release. It
> > > has to be related to createInstance... I am listed in components.reg and
> so
> > > on so it is not a lookup problem. I think there is a match up problem
> > > between my dll and the release Mozilla, like we built differently or
> > > something.
> > > Thanks for your help,
> > > -john
> >
> > Two registration-like things have to happen before a component
> > can be instantiated from JS... The dll needs to have been
> > autoregistered and the .xpt file also needs to have been
> > autoregistered. For debug builds the application will scan for
> > new dll and xpt files in the components directory on each
> > startup. For Release builds this is not the case. You need to
> > force this by: running regxpcom or deleting component.reg and
> > xpti.dat before startup. Both these autoreg activities can also
> > be triggered programatically at runtime via a method on the
> > component manager object or (in newer builds) by calling
> > navigator.plugins.refresh().
> >
> > Are you sure your component got correctly registered in your
> > *release* component.reg? You can easily check for your xpt file
> > in xpti.dat since this is a human readable file (but do yourself
> > a favor... don't edit that file). You sound like you are sure
> > that registration issues are not the problem. But these really
> > are the mostly likely causes of what you describe.
> >
> > John.
