C
Craig in NJ
MSHTML IOmHistory's .history.go("<URLstring>") consistently causes my
history stack to get messed up. Can anyone [who has used .history.go(
) ] confirm this bug and my workaround?
I'm using IE6.0 SP1 and accessing the webbrowser object (actually I'm
using the internetexplorer object) via Excel 2000 SP3 VBA.
Here's how to see the bug:
In VB/VBA, start an instance of internetexplorer (or maybe webbrowser),
make it visible, etc, and then interrupt your code so you can debug in
in the immediate window. I'm assuming you already have some code lying
around which uses the .history. that will take take you that far. Then
follow these steps manually (or programatically if you prefer):
1. Manually navigate to a web page that you'll want to go back to via
..history.go. E.g., http://my.yahoo.com
2. Manually navigate to a few other pages on the web, sequentially, to
build up the history stack.
3. In your debugging immediate window, use the .history.go command to
jump back to your target page, e.g., in my case this would be:
IEwindow.Document.parentWindow.history.go("http://my.yahoo.com/")
(or use the .script.history.go variant if you prefer; the effect seems
the same).
Note: If your history.go command gives you an access denied error as I
get for some pages (e.g., ones in my own root 2nd level domain seem to
suffer this), manually navigate forward to one that is safe like
..navigate("about:blank"), and try the .history.go again.
So far so good. The history.go should've worked fine, and the history
stack under the pull-down Back and Fwd menus of IE should look like
you'd expect.
4. Now manually "click" on one of the links on this successfully
gone-back-to page (a news article, for example), and then manually look
at the pull-down Back & Fwd history stacks. Surprisingly, the
successfully gone-back-to .history.go page (http://my.yahoo.com)
doesn't appear as the latest page in the Back pulldown menu stack;
instead it appears as the farthest-forward item in the Fwd pulldown
menu stack (and, of course, it'll disappear completely if you click or
navigate onward to anything else). At least that's what I'm seeing.
This is a royal PITA for me because in my VBA application I needed to
repeatedly go back to a page with a list and "click" into links there
and maybe click further from there, and then jump back to the page with
the list to do it again for some other links on the list. But after
the 1st iteration of this, my list page disppears from the stack, so my
VBA code can't go back to it!
The only workaround I've found is to "wiggle" using
GoBack : GoForward
immediately after the successful history.go("...").
Can anyone [who has used .history.go] confirm this bug?
I really wish there were a more efficient way to get the history stack
to fix itself than wasting time doing this wiggle. (My other
workaround is to use .GoBack repeatedly an unpredicable number of times
until I reach the target URL, but that seems like it could be even less
efficient, especially if a user browsed around enough to make the
target URL disappear from the history stack.) Is there a more
efficient workaround than the GoBack:GoForward wiggle?
BTW, I also wish I didn't need to waste time & effort doing a
..navigate("about:blank") to avoid getting the access denied error when
I use history.go("..."), too. If you've got a better solution to that,
too, I'm all ears.
Craig in NJ
- not an expert with this stuff; just stumbling my way through trying
to make my real job easier by using Excel VBA.
history stack to get messed up. Can anyone [who has used .history.go(
) ] confirm this bug and my workaround?
I'm using IE6.0 SP1 and accessing the webbrowser object (actually I'm
using the internetexplorer object) via Excel 2000 SP3 VBA.
Here's how to see the bug:
In VB/VBA, start an instance of internetexplorer (or maybe webbrowser),
make it visible, etc, and then interrupt your code so you can debug in
in the immediate window. I'm assuming you already have some code lying
around which uses the .history. that will take take you that far. Then
follow these steps manually (or programatically if you prefer):
1. Manually navigate to a web page that you'll want to go back to via
..history.go. E.g., http://my.yahoo.com
2. Manually navigate to a few other pages on the web, sequentially, to
build up the history stack.
3. In your debugging immediate window, use the .history.go command to
jump back to your target page, e.g., in my case this would be:
IEwindow.Document.parentWindow.history.go("http://my.yahoo.com/")
(or use the .script.history.go variant if you prefer; the effect seems
the same).
Note: If your history.go command gives you an access denied error as I
get for some pages (e.g., ones in my own root 2nd level domain seem to
suffer this), manually navigate forward to one that is safe like
..navigate("about:blank"), and try the .history.go again.
So far so good. The history.go should've worked fine, and the history
stack under the pull-down Back and Fwd menus of IE should look like
you'd expect.
4. Now manually "click" on one of the links on this successfully
gone-back-to page (a news article, for example), and then manually look
at the pull-down Back & Fwd history stacks. Surprisingly, the
successfully gone-back-to .history.go page (http://my.yahoo.com)
doesn't appear as the latest page in the Back pulldown menu stack;
instead it appears as the farthest-forward item in the Fwd pulldown
menu stack (and, of course, it'll disappear completely if you click or
navigate onward to anything else). At least that's what I'm seeing.
This is a royal PITA for me because in my VBA application I needed to
repeatedly go back to a page with a list and "click" into links there
and maybe click further from there, and then jump back to the page with
the list to do it again for some other links on the list. But after
the 1st iteration of this, my list page disppears from the stack, so my
VBA code can't go back to it!
The only workaround I've found is to "wiggle" using
GoBack : GoForward
immediately after the successful history.go("...").
Can anyone [who has used .history.go] confirm this bug?
I really wish there were a more efficient way to get the history stack
to fix itself than wasting time doing this wiggle. (My other
workaround is to use .GoBack repeatedly an unpredicable number of times
until I reach the target URL, but that seems like it could be even less
efficient, especially if a user browsed around enough to make the
target URL disappear from the history stack.) Is there a more
efficient workaround than the GoBack:GoForward wiggle?
BTW, I also wish I didn't need to waste time & effort doing a
..navigate("about:blank") to avoid getting the access denied error when
I use history.go("..."), too. If you've got a better solution to that,
too, I'm all ears.
Craig in NJ
- not an expert with this stuff; just stumbling my way through trying
to make my real job easier by using Excel VBA.