This content has been marked as final. Show 8 replies
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.
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.
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.
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.
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.
In WebHelp, I don't use the META refresh technique. Maybe FlashHelp will accept the same method.
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.
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?