The ActiveX control is part of the GRE, but doesn't work most probably because there is no chrome. What's the best way to get it working? Do we intend to ship a default bunch of chrome?
Adam, we already ship some default chrome - as part of embed.jar - which gets installed into the GRE's chrome dir.
Hmm, the GRE I just downloaded from latest on ftp.mozilla.org didn't install any chrome. I'll try again, perhaps it didn't download correctly.
it used to work fine...May be Sean's latest GRE install changes broke it...i'll also try.
Adam, you're correct - the "chrome" dir is missing.. I'll file a bug on Sean.
Adam...please ignore my comments above. Sorry, i was'nt thinking right. The "GRE app support" files, which reside in the chrome/res/default dirs, are part of an application and not the GRE. That's why you're not seeing the "chrome" dir when you install the GRE. For ex, when MfcEmbed is installed to use a GRE the chrome dir will be installed as part of the MfcEmbed installer. So, to fix this bug, i guess we have to add the missing chrome files to Mozilla's chrome dir.
Looking over the bugs related to XRE comments and now the activeX control, it looks as if there is now the GRE and the second grouping of files known as the "GRE App Support" files. As more and more apps roll out and use the common functionality provided by the runtime, depending on the functionality that the apps wish to use, they will need to figure out which app support files need to be included in their own application to make it work with the GRE. Is this our intention, or is this why we are tossing around the idea of the XRE?
Summary: GRE enable ActiveX control → [ActiveX] GRE enable ActiveX control
*** Bug 208396 has been marked as a duplicate of this bug. ***
Not just chrome/ but defaults/ and res/ are also important to the control. I have verified that if I copy all three of these things from an embedding dist to the GRE dir that the control is happy once more. More importantly, Mozilla 1.4 also continues to function normally when these files are there. So as a workaround I might be able to produce some kind of control pack that must be unzipped into the GRE dir to make it work, but the ultimate solution is to bundle up the control with these things for itself and make it a GRE consumer. This means breaking the runtime dependencies the control has on xpcom.dll. So the first step is to test if the control can be built with XPCOM glue to break this dependency. Bug 206901 covers some reworking of the activex builds so I might be able to tie it into that. If so, it should be possible zip up the control somewhere else, remove it from the GRE and ship it as a seperate add-on package. As the control reaches into the ever changing bowels of Gecko it will still be tied to a particular GRE however.
In response to comment 6, we do have a gre-win-supp file in mozilla/embedding/config. Running "make gre" creates a dist/gre and gre/gre_app_support. This gre_app_support dir only appears in an mfcembed sample package in xpinstall. So as it stands, the client app is expected to ship with these files, even though for the most part they'll not be changing the contents. The issue for the control is complicated because although it is a client of the GRE, other apps are clients of the control. So unless the working dirs of these apps all contains the support files they won't work. I know that copying them to the GRE does work, and I'm not aware of any side effects of doing so. SoI wonder if the GRE itself should ship with a default support files, and be used in the absence of any in the client.
I have put a .zip file on my site which supplies the missing files. Backup the original GRE (to be safe) and unzip this on top of it. http://www.iol.ie/~locka/mozilla/gre_app_support14.zip The control should be happy then.
*** Bug 210854 has been marked as a duplicate of this bug. ***
*** Bug 206429 has been marked as a duplicate of this bug. ***
Is there another location I can get the "missing files". I can't access http://www.iol.ie/~locka/mozilla/gre_app_support14.zip from work - DNS lookup problem. Ta, paul
Thanks to Bill Mason for sending me the files. The control now works in HTML-KIT (http://www.chami.com/html-kit/) and allows me to preview html files via the control from within the application. I can now also add the control to a form in Delphi 5 without the whole thing locking up as it did without the additional files. [I can't modify a number of the properties of the control via the object inspector in Delphi but as I'm unfarmiliar with the control maybe I'm doing something wrong). Paul
May I humbly suggest that the future builds of GRE ship with the contens of the above mentioned ZIP. Finally some developers started to embed Moz and almost instantly the rug is jerked out. Now they are expected to re-write to get it working again. Very Microsoft. It will make developers more likely to embed that control if they don't need to provide all the chrome.
Still not functional as delivered in 1.7's GRE.
(In reply to comment #16) > Still not functional as delivered in 1.7's GRE. There is now (and has been since v1.5) a separate installer for the control that installs a separate GRE,the control and support files and registers the control. This is currently the correct way to install the control. A v1.7 test version (v1.7t1) has been available since 12/04/2004 and works well apart from a few problems with new features. You can download it from Adam's web site: http://www.iol.ie/~locka/mozilla/MozillaControl17t1.exe
Status: NEW → RESOLVED
Last Resolved: 9 years ago
Resolution: --- → INCOMPLETE
Component: Embedding: ActiveX Wrapper → Embedding: ActiveX Wrapper
Product: Core → Core Graveyard
You need to log in before you can comment on or make changes to this bug.