ODL vs IDL

Copied for longevity

(from the great Igor Tandetnik):

The difference is not between ODL and IDL - you can change the file
extension to .idl and it will behave exactly the same way. The
difference is in the file structure.

The way MIDL compiler works, .h file is generated based on the
declarations _outside_ the library block. TLB is generated based on the
declarations inside the library block. The usual approach is to defined
all the interfaces (and structs and enums) outside the library block,
then mention them inside (usually as part of coclass statement). This
way, you would get them both in the header file and in TLB.

Your ODL file, I bet, defines everything inside a library block.

(from the great Alexander Nickolov):

If you deselect ODL mode for your MFC project, you must also
rename it with IDL extension since it's no longer an ODL file.
ODL = Object Description Language - only describes type libraries
IDL = Interface Definition Language - describes both interfaces and
type libraries (contains ODL as a subset).

Historically, initially IDL coudn't be used for type libraries, so
Microsoft invented ODL. Later they joined the two languages
under the IDL name. IDL itself is inherited from OSF DCE RPC
spec and extended to support COM interfaces. It does contain
the original IDL as a subset - you can still use it to define RPC
interfaces (e.g. don't specify [object] for the interface).

Catching HTTP 401/403 using Java SWT IE Browser

I've been working on a bit of Java code which needs to handle an HTTP proxy authentication failure, the code in question uses IE via the SWT browser and unfortunately I've discovered that you cannot chain onto the NavigateError event!

The event is handled inside IE.java (SWT source) but just does some specialised UNC handling without giving you the opportunity to do something useful (like catch the HTTP status code). As such I've had to restort to using an additional connection using HttpURLConnection and Authenticator.setDefault() / getPasswordAuthentication() - which is wasteful as I'm now having to make two connections to the webserver...

It's not even as if you can derive a new class from org.eclipse.swt.browser.IE because the required member variables have default visibility which means anything outside the org.eclipse.swt.browser package can't access them :(