Embedded WebBrowser won't work in WSH?

[JJ]

By "embedded WebBrowser", I meant the `Shell.Explorer` object.

Using either `Navigate` or `Navigate2` to open `about:blank` causes
0x80004005 "Unspecifier error" exception. Even checking its `busy` property
causes the same error.

Anyone managed to use the embedded WebBrowser from WSH?

[Mayayana]

"JJ" <***@gmail.com> wrote

| By "embedded WebBrowser", I meant the `Shell.Explorer` object.
|
| Using either `Navigate` or `Navigate2` to open `about:blank` causes
| 0x80004005 "Unspecifier error" exception. Even checking its `busy`
property
| causes the same error.
|
| Anyone managed to use the embedded WebBrowser from WSH?

Isn't that the same as the WebBrowser control? And you're
just writing a VBS where you use CreateObject("Shell.Explorer")?
That's a control, requiring that it be set in a window. You'd
need something like a DLL with a window and dispatch binding to
provide it. But it's the same as IE, so why not use IE?

[JJ]

Post by Mayayana
Isn't that the same as the WebBrowser control? And you're
just writing a VBS where you use CreateObject("Shell.Explorer")?
That's a control, requiring that it be set in a window. You'd
need something like a DLL with a window and dispatch binding to
provide it. But it's the same as IE, so why not use IE?

Yes, it's the WebBrowser control. Not all ActiveX controls need a window. A
view can be used without a parent window. It depends on the implementation.
I just wasn't sure whether WebBrowser control requires a parent window or
not.

I'm currently using IE remoting because that was the only solution so far. I
just don't like having to use separate process, because if an unexpected
error occurs and the script terminates, the separate process would become an
orphan and I'd have to manually terminate it.

[Mayayana]

"JJ" <***@gmail.com> wrote

|
| Yes, it's the WebBrowser control. Not all ActiveX controls need a window.
A
| view can be used without a parent window. It depends on the
implementation.
| I just wasn't sure whether WebBrowser control requires a parent window or
| not.
|
| I'm currently using IE remoting because that was the only solution so far.
I
| just don't like having to use separate process, because if an unexpected
| error occurs and the script terminates, the separate process would become
an
| orphan and I'd have to manually terminate it.

I've never noticed that object before, but I do find I can
mount it in an HTA with the following:

<OBJECT ID="WB" CLASSID="CLSID:8856F961-340A-11D0-A96B-00C04FD705A2"
width=600 height=400> </object>

I can then navigate to a local HTML file via script. I don't know
if that's of any value to you. It would, at least presumably be in
the same process.

Or is it the same process? I don't know. Spy++ shows it with
an Internet Explorer_Server and a second one under that. But
a WB generally does its own thing. I'm not sure it's ever in-process.

[JJ]

Post by Mayayana
I've never noticed that object before, but I do find I can
<OBJECT ID="WB" CLASSID="CLSID:8856F961-340A-11D0-A96B-00C04FD705A2"
width=600 height=400> </object>
I can then navigate to a local HTML file via script. I don't know
if that's of any value to you. It would, at least presumably be in
the same process.
Or is it the same process? I don't know. Spy++ shows it with
an Internet Explorer_Server and a second one under that. But
a WB generally does its own thing. I'm not sure it's ever in-process.

It's in the same process, yes. WebBrowser is an embedded IE. It doesn't
require external process to actually host IE. The embedded IE is actually
hosted in the process which creates the ActiveX control. It may create
additional (hidden) windows, but it won't create new process - at least for
hosting IE.

However, the script I wrote is for console use, so it needs to be run from
WSH. If combined with HTA, it would be the same case as IE remoting if the
WSH script encounters an unexpected error and abruptly terminates - where
it'll make the HTA process an orphan.

But I just realize that I could use `PutProperty()` & `GetProperty()` to
mark the remote IE instance, so that it can be identified as "an IE instance
created by this script" and be reused or closed.