[thelist] Alternate means of communicating between IE and external application

Roger Ly rogerly at bareviking.com
Tue Feb 11 10:23:00 CST 2003

Hey all,

I am looking to revamp a Windows-only Java application we that design
that requires the ability to receive communication from an IE browser.

Quick background:  The application is written to MS's
soon-to-be-completely-unsupported JVM, and uses MS's WebBrowser control
to embed a web browser component in a Java frame to serve local HTML
files from disk.  This is the same WebBrowser control that you can use
to embed a browser in your VB or MFC application, just ported to Java.

Anyways, we currently allow the browser to communicate to our
application by embedding an Active-X control on the local file being
displayed in the browser, so if a user decided to click on a link that
needed to do something in our application, it would use the Active-X
control as a proxy to send commands to our application.  Obviously, that
requires a user to accept our Active-X control in order for any of this
to happen (which hasn't been a problem for us, just a hassle to

That being said, I've been looking to alternatives to this approach.  I
can't seem to find anything that let's me automatically do anything with
an external application except launch it as an external viewer for
unsupported file types.  I'd really like to be able to have something
that allows a user to send information (via COM, JNI, LiveConnect, etc.)
from my browser to an external application (note that this is a
standalone application, and not an applet being served by a browser, so
LiveConnect is probably out of the question).

Does any one have any obvious ideas as to other approaches.  When
originally designing the system a few years back, Active-X seemed like
the only reasonable solution, but it is possible that new
ideas/technologies have come about in the recent past.

Also, please no lectures about writing to the MS JVM, at the time of
designing the app, MS was much faster than SUN, and we were only
supporting Windows OSes.  We are looking to port to either the SUN JVM,
or possibly porting straight to native code (either by writing the
native code by hand, or using something like Excelsior's JET native
compiler to compile the SUN bytecode to native code), but this problem
will still be around no matter what approach we take.



More information about the thelist mailing list