Vista - Windows Explorer vs Internet Explorer on Vista

In the good old days of XP and IE 6, it used to be
the case that Windows Explorer and Internet Explorer
were pretty much the same thing with only minor
(though significant) differences.

In particular, if you wanted an Explorer flavour of IE,
what you could do was to instantiate a
Shell.Application object and use its Open property
to kick off an instance of Windows Explorer.
By using the WindowRegistered event handler
function of the Shell.Application->windows object,
you could trap for this newly created instance of
Windows Explorer. At this point, you could then do
Navigate2 "about:blank"
on said Windows Explorer object and it would turn
into an IE object. Tada.

Now what happens under Vista (Business) and IE 8
is that when you do the Navigate2 "about:blank" hack
then all of a sudden, instead of Windows Explorer
turning in IE, A new program (with a differently sized
window) starts up, which might be Firefox, IE or some
other browser, and Windows Explorer goes poof.
Even if I set the default browser to IE 8, I get this
same effect.

My question: I don't suppose anyone knows of a
way to get the XP / IE6 legacy style of behaviour.
Perhaps there is some obscure flag or such. My
interest in this is that the title bar of Window explorer
is much more amenable for the functionality that I
have in mind, which is that I want to use "Windows
Explorer/IE" as a canvas to host my own script
application.

Thanks for any thoughts,
Csaba Gabor from Vienna

Csaba Gabor wrote:I don't think so. Blame the competing browser manufacturers who took MS
to court and won an antitrust ruling that forced MS to remove that
functionality.
--
HTH,
Bob Barrows

I'm not clear about the advantage of the
Explorer window. The title bar is more
easily customizable? Don't they both just
show the current location (With IE also
showing the OEM string if there's one in
the Registry)?

I wonder if you could recreate what you need
with an HTA or some such. I'm not familiar with
the WindowRegistered event and how you're
using it, but I imagine that MS probably made
the change as an update/security measure. IE
and Explorer have not actually been related since
WinME. Only Active Desktop systems have an
IE window in the folder view. (Even on AD systems
the connection between IE and Explorer is as much
marketing as it is actuality.)

As of XP, the Shell object model is really a
compatibility holdover. The design of ShellWindows,
returning Explorer *and* IE instances, never made much
sense, but at least there was actually an IE browser
window buried in Explorer instances when they wrote
that object. And it was possible to access the actual
browser window (though not directly through VBS).
Since XP there's really no connection at all. There's
no IE browser window in folders. (Even though each
Window item is officially an IE object, the IE.document
is just a dummy placeholder that really returns a
ShellFolderView object.)

MS is just stuck with the IE/Explorer marketing tie-in
from the 90s and need to support old code.

In light of all that it seems to make sense that
MS has "cleaned out" unnecessary IE functionailty
from the Shell object, as much as they can. The Open
method, after all, is supposed to open an Explorer folder
window. There's no reason that one should be able to
jump from there to an IE instance.

...Which is to say that I doubt that functionality is
coming back. I'm still using IE5 and it's a pleasure.
I can do all sorts of things with it. But with later versions
of IE it doesn't seem realistic to use it for anything
but HTAs.

Thanks for your comments Mayayana and Bob.

Mayayana, in regards to your question about the
title bar of Explorer vs. IE, Explorer's title bar is
not suffixed with a Microsoft Internet Explorer
(or whatever the latest text is). Therefore, by using
Explorer instead of IE, it is possible on systems
where you can get to IE from Explorer to create
an app hosted in Explorer/IE with a Title bar that
doesn't have extra cruft in it. This was the only
way that I know of to achieve this without some .ocx
helping out (and even then it was not trivial,
and I don't know if my solution works in current
versions. MS really doesn't like one fooling with
that title bar, nor the address bar).

WindowRegistered is an event handler function
that you can set on the Windows collection of
the "Shell.Application" object. It gets fired
whenever a new Explorer or IE is instantiated.
If you want to grab ahold of a new Explorer
that you are just instantiating, that event
handler is your point of access.

On Sep 25, 4:20*pm, "mayayana" <mayaXXy...@newsgroup> wrote:

Therefore, by using
Explorer instead of IE, it is possible on systems
where you can get to IE from Explorer to create
an app hosted in Explorer/IE with a Title bar that
doesn't have extra cruft in it.I see. There is a setting, at least with older
versions, whereby you can remove "Microsoft
Internet Explorer" by setting
Software\Microsoft\Internet Explorer\Main\Window Title
to "" in HKLM and HKCU. But of course that's a bit
intrusive if you're shipping your utility to others.
WindowRegistered is an event handler function
that you can set on the Windows collection of
the "Shell.Application" object. It gets fired
whenever a new Explorer or IE is instantiated.
If you want to grab ahold of a new Explorer
that you are just instantiating, that event
handler is your point of access.Thanks. I'd never heard of that.