Browse sequences and topic jumps

[kcasper]

Hello all, I'm in need of your expertise.

I use RH7 for Word and Word 2003. I have browse sequences that match my TOC for each of the 27 chapters within my help project. When I got to the Browse Sequence Editor each topic appears there and is correctly ordered. However when I generate output there are very few topics that don't 1) refuse to browse forward 2) refresh only to themselves over and over again, no matter how many times you click the forward button 3) jump to the middle of the next topic rather than the heading or 4) don't appear at all.

I've already had one un-fixable problem this week that resulted in replacing 897.SHG images with .BMPs because my popups were corrupted. Now I may have to remove all browse sequences from my help as well, as I can't release a version to our customers that appears broken everytime they click forward. With no interactive images and no browsing, I'm beginning to wonder what the point is of creating a Winhelp file! I'm about to give up and consider recreating my entire help file (all 3500 topics) in any other authoring software I can find.

Any insight you can provide, and thus further my sanity, would be greatly appreciated.
Thanks, Kristin

[HKabaker]

Kristin,

(Oops, on rereading your post, I realized you're doing WinHelp. So I'm deleting what I said for WebHelp.)


Harvey

[Guest]

Hi, Kristin.

Sometimes it helps my sanity to know that others feel my pain. I certainly feel yours. I wailed aloud when I had to give up WinHelp output, and again when I switched to RoboHelp HTML (which, as far as I am concerned, is an entirely different help authoring tool from RoboHelp for Word).

The thing is, I'm not sure that you're going to get any better results with a different authoring tool for WinHelp files. They haven't been the officially supported format for Microsoft for years, and that put a chill on the authoring tools - complicated by the fact that the authoring tools needed to change to respond to the changes in the software around them.

I wonder if changing your output to HTMLHelp (.chm) would help you? It's a single-file output like WinHelp, and I believe RH Word produces it. It would be pretty easy to test-generate your existing project into a .chm and see how the browse sequences work. There are some security issues with .chm files, but I don't think they apply if you distribute the .chm to the user's PC along with the application, the way you do with .hlp.

I am not suggesting changing your source files/authoring tool to RoboHelp for HTML. Someday it may come to that, but from the stats you quoted, it sounds like a big project that would be difficult to convert.

HTH,
Elisa

[kcasper]

Thanks for the advice! I tried what you suggested, and generated to WebHelp output instead - everything appears to work as it should and flows even better than it did before! I'm not sure why I didn't do this forever ago, other than the unkonwn of how it might change my (apparently cranky) help output. However I've never done anything with WebHelp, so that leads me to ask a few questions.

1. Can each webhelp page be linked back to my software app. so that the user can still click the F1 button while in a program, and see the applicable help topic? My programmers haven't done this before, they've always used the Map IDs to link Winhelp topics back to each screen in our software. Obviously with limited success.

2. Could the entire help system be somehow hosted on our website, so that our customers would no longer have to download each new version of the help onto their PCs, but instead access the latest pages straight from the web?

Thank you for your input - it's been immensly helpful!
Kristin

[Guest]

I'm delighted that the new format worked for you.

For the sake of the forum, though, we need to be very sure about something. Is your new output WebHelp (a whole pile of HTML files) or HTMLHelp (one .chm file)? Because the answers to your questions vary with the output you generate.

That said,

1) Yes, you can link to your application. You may even be able to do it with your current mapIDs. What you are looking for is context-sensitive help, and I'm no expert on it, but the really basic version is something like this:

a) The application "calls" the help topic by activating a command in the code when F1 is pressed. Different application languages have different commands (APIs) to call help.
b) The help call in the application contains some way to identify the topic. Usually this is a map ID.
c) This is where it gets a little gnarly. The map ID in the help call is linked to the topic in RoboHelp. There are different ways to do this, and I don't know precisely which applies to your situation. I would read RoboHelp's own online help about context-sensitive help, map IDs, map files, and alias files.

Also, I would look on www.robowizard.com and www.grainge.org for more help. They are full of great information.

2) Yes, you can certainly put the help on your company website and let the application users connect to it at runtime - IF you are really generating WebHelp. You don't need to buy RoboHelp Server to do this, either - RoboHelp Server is a product to provide extras like hit reporting for dedicated help servers.

All you have to be careful of is your help output format. HTMLHelp .chms don't work well over the web because internet security views them with extreme suspicion.

HTH,
Elisa

[kcasper]

Elisa, the output I generated was actual WebHelp (the whole pile of .html files) so hopefully we can simply switch out the new calls for the old, and have it work as it should. I'll have to do some additional research into how to instruct my programmers to link the new pages.

Thank you!

[MergeThis]

The easiest calls from the app are to URLs (e.g., the apps' MainUserFrm window calls for your MainUserFrm.htm topic). This avoids all API angst!


Good luck,
Leon

[Guest]

Hello - I see this is an old problem, and I'm glad you don't have to deal with it anymore, but I was wondering if you (the original post-er, if you're still on the Forum) could remember how your "corrupted popups" problem manifested itself? And did you end up making new .shgs or did you have to just give up on clickable graphics for that project? And of course I'd be grateful for anyone else's help as well.

I am in RoboHelp 8 (with all applicable service patches), using Word 2007 in compatibility mode, on Windows XP if that matters. We have an enormous, multi-.hlp system that we are required to generate as an .hlp and then as WebHelp. (Don't ask me why 🙂 ).

My problem is that in this enormous project, out of all our many .shgs, there are about 4 of them that have stopped working. I found the problem when I looked in my Broken Links section of the Explorer pane and saw a bunch of bizarre, one-letter topic IDs. They were all in these 4 .shgs - all the topic IDs that were being called from all the hotspots in these .shgs had simply disappeared and been replaced with single random letters.

I have deleted the .shgs, gone back to the .bmp, and redrawn them more than once. I was able to get them to stay in place for one WinHelp compile, but then when I went to generate the WebHelp output they were all back again.

(I considered giving the topics an alias of that one letter as a workaround, but unfortunately all of the one-letter context strings seem to be called by more than one .shg.)

This is perhaps the wackiest thing I have seen in 10+ years of working with RoboHelp, and that's saying something :-). Has anyone seen this before? Thank you,

Sandy