Redirect JS problem in RH 7

[HKabaker]

Some of us have been using a redirect script to open a new window with contents outside the current WebHelp package.

For example in a WebHelp package called ABC Help,

A TOC line says "XYZ Help" and points to a topic with no text. It contains the following in the < head >...< / head> section (without the extra spaces after the bracket < ):

< script language=JavaScript1.2 type="text/javascript" >
< !--Redirects to XYZHelp package in a new browser window
window.open("XYZHelp/help.htm")
// -->< /script>

The result until now was to open XYZ Help in a new window, leaving ABC Help open in the background.

In RH 7, after XYZ Help opens, ABC Help comes back on top showing the blank topic that called XYZ help.

Working with separate copies of the same project in RH 6 and RH 7, I've tried any number of changes to make the RH 7 redirect topic look like the RH 6 version. I got rid of breadcrumbs and search highlight, and took out some other stuff that RH 7 does now, to no avail. In RH 7 I undid all of my patches that fixed some browser display problems in RH X5 and RH 6, which I had carried into RH 7.

Still, ABC pops up on top of XYZ.

I' ll try another approach, making the TOC entry use a relative path path to XYZ outside ABC but in the same neighborhood.

Has anyone else run into trouble with the redirect script?

Harvey

[Cro1410]

HI Harvey,
I had pbs with redirect scripts as well. Removing the 'Mark of the web' option always resolved this pb.
However, the script that you specify is not a redirect script per say (document.location='<filename.htm>';) so am not sure this will help you.

[HKabaker]

Chris, thanks.

I don't use mark of the Web.

I think document.location just fills the topic pane with the substitute topic.
I need to open a new window.

I just had an inspiration to try next time.

I'll move my script down so it's after all the RH scripts (remember, there's no text, but RH puts some scripts in the < body> section). Then I don't care if RH puts breadcrumbs into the blank topic. By the time anyone woould see them, the new window should be on top.

If I put the script in the source topic body, RH might trump me with its last script. In that case, I'll have to edit the output file.

Any other ideas are welcome.

Harvey

[MergeThis]

Harvey:

Instead of JS, you could use the meta refresh method:

< meta http-equiv=refresh content="0;URL=targeted_file.extension" >

Increasing the value of "content" would enable a delay in launching the target, if you might want to provide some text like "Retrieving the file requested blah, blah..." I'm guessing you could also include the new-window HTML control TARGET="_blank" here, although I haven't tried that myself for these redirects.


Good luck,
Leon

[HKabaker]

FWIW, I've tracked this down.

It's the TOC sync function. In every topic, RH 7 puts some code that tests for the flag it had set when you generated with the TOC sync option selected. The flag kicks off a call to the sync function in a separate file.

When I'm working on my hard drive, RH can sync the TOC quickly, before the new window opens. But over an Inter/Intranet, depending on the TOC size (and especially if you're jumping from merged WebHelp), the new window opens on top and gets pushed to the background when TOC sync finishes.

My solution is to delete the TOC sync code from the output file for "topics" that function only to jump out.

The first WebHelp window stays open in the background with a blank topic, or just with breadcrumbs if you selected that option. Writing breadcrumbs is fast enough, so the new window stays on top. There's also some search highlighting code that doesn't interfere.

Harvey

[Epiphytos]

Hi - interesting thread! I have a similar problem in one of my help files. I have a redirect in a meta statement for some of my topics - most really. The statement looks something like this:

<meta http-equiv=Refresh content="0 url=http://minerva/page_sample.asp">

I do this because my asp pages contain database calls so that each time a user loads one of these pages, they get the most up-to-date information possible.

However, with RoboHelp 7 for FlashHelp, the system clobbers my meta statement and substitutes a generic one:

<meta http-equiv="Refresh" content="text/html; charset=utf-8">

So these pages all stay blank, and fail to redirect. I have attempted to change the way the system generates the files to try to resolve the issue:

1. Removed Mark of the Web
2. Removed Browse Sequences
3. Removed Synchronize Table of Contents (for the entire project)
4. Removed Breadcrumbs Links

None of these actions has fixed the problem. I'd like the program not to clobber my html. Any thoughts would be most appreciated.

[HKabaker]

In WebHelp, I don't use the META refresh technique. Maybe FlashHelp will accept the same method.

In the body of the topic, just before the <end html> line, insert a javascript to redirect the topic pane. Something like,

[Epiphytos]

Thanks for that reply, Harvey.

Yes, I've been using the META tag redirect method for about 5 years now, with good success in WebHelp and FlashHelp. Only with the elimination of KADOV tags in RoboHelp 7, a much anticipated event, has my project broken. It would seem that what were once used in KADOV tags for RoboHelp functionality, have been moved to more standard tags and code.

In any case, I have also found that Javascript redirect method correctly substitutes for the META tag redirect method. Here's a code snippet that's working for me now in my project:

<!-- Javascript code to redirect this page to an ASP page on another network location>
<script language="JavaScript">
function redirect()
{
window.location.href=" http://minerva/aspFile.asp";
}
</script>
</head>
<body onload="javascript:setTimeout('redirect()',500)">

That's very similar to your own approach - and it's working! By the way, the main reason I have been doing this all these years is because I was not able, previously, to add ASP pages to a RoboHelp project. Do you know if that's still the case?

Thanks again,

Andy

[RoboWizard]

Welcome to our community, Andy

I too found that my redirects were getting clobbered. Seems if I rearranged where I inserted them in the list of meta statements, they would be preserved.

But the point is probably moot, as I see you have discovered the JavaScript workaround.

Cheers... Rick