On Jul 25, 6:24 pm, Robin Berjon <[EMAIL PROTECTED]> wrote: > Hello, > > I'm working on a rather large Gecko-based app, and I'm hitting on > some pains that seem due to Gecko either caching XPCOM IDL > definitions, or giving some priority to XPTs that I don't know where > to find. The process I use to hack on the JS XPCOM bits is this: > > - modify JS (and if applicable the IDL, in which case the XPT is > regenerated) > - kill the app > - copy the modified JS and XPT to $MY_INST/xulrunner/components > - kill $MY_PROFILE/xpti.dat and compreg.dat > - restart the app > > Now this works in two cases: > > - either this is a completely new interface that has not yet been > added to the build > - or only the JS has been modified > > But if the IDL/XPT has changed, then it's not taken into account > unless I commit and wait for a build to come out from our farm. I > tried changing the UUID and ProgID in the hope that that might work > (despite being cumbersome) but it doesn't fly. Renaming the interface > works but that means changing a lot of code uselessly every time. > > So is there a way of getting Gecko to pick up the new XPT correctly > that I haven't found?
in some scenarios xpti.dat/compreg.dat live in a profile directory, something like: C:\home\Application Data\Mozilla\Firefox\Profiles\RANDOM.MineField 07/22/07 02:52 AM 98,592 xpti.dat 07/22/07 02:52 AM 149,802 compreg.dat In the old days, .autoreg was your friend. _______________________________________________ dev-tech-xpcom mailing list [email protected] https://lists.mozilla.org/listinfo/dev-tech-xpcom
