Neil wrote:
Neil wrote:
OK, so I recompiled with better configure options and ColorZilla
works perfectly.
Except you said that ZIP builds don't have the problem, do they? I
guess the next thing is to see if I can build an installer...
OK, so I now have an installed build and ColorZilla doesn't work. So far
I've only tried loading it under Dependency Walker which shows
ColorZilla trying to dynamically load xpcom.dll from the wrong location
i.e. not the GRE. The thing is, on my Netscape 7.2 the following
expression (which I was crashing before, which is why I know it was
being used by ColorZilla):
Components.classes['@mozilla.org/file/directory_service;1'].getService(Components.interfaces.nsIProperties).get("XpcomLib",
Components.interfaces.nsIFile).path
actually also evaluates to the wrong location.
As it happens, copying xpcom.dll to components/ makes ColorZilla work.
But what I can't figure out is why ColorZilla is trying to load
xpcom.dll in the first place...
If you get a chance before I do, can you try deleting compreg.dat and
running Mozilla 1.7 under depends.exe to see a) what that expression
evaluates to b) whether anything tries to load that c) whether it succeeds?
_______________________________________________
Project_owners mailing list
[email protected]
http://mozdev.org/mailman/listinfo/project_owners
