190181 - [ActiveX] GRE enable ActiveX control

Status: RESOLVED INCOMPLETE

(Core Graveyard :: Embedding: ActiveX Wrapper, defect)

Description

[Adam Lock]

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?

Comment 1

[Chak Nanga]

Adam, we already ship some default chrome - as part of embed.jar - which gets
installed into the GRE's chrome dir. 

Comment 2

[Adam Lock]

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.

Comment 3

[Chak Nanga]

it used to work fine...May be Sean's latest GRE install changes broke it...i'll
also try.

Comment 4

[Chak Nanga]

Adam, you're correct - the "chrome" dir is missing..

I'll file a bug on Sean.

Comment 5

[Chak Nanga]

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.

Comment 6

[Charles Rosendahl]

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?

Comment 7

[Adam Lock]

*** Bug 208396 has been marked as a duplicate of this bug. ***

Comment 8

[Adam Lock]

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.

Comment 9

[Adam Lock]

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.

Comment 10

[Adam Lock]

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. 

Comment 11

[Adam Lock]

*** Bug 210854 has been marked as a duplicate of this bug. ***

Comment 12

[Adam Lock]

*** Bug 206429 has been marked as a duplicate of this bug. ***

Comment 13

[paulGittings]

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

Comment 14

[paulGittings]

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

Comment 15

[CharlesTaylor]

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. 

Comment 16

[John A.]

Still not functional as delivered in 1.7's GRE.

Comment 17

[irongut]

(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