Build XML Target in Robohelp Equivalent in Flare

[mrsvolunteertoomuch]

In Robohelp, I could batch generate HTML Help and XML help. When I compiled XML help, I received a file named the project's name that contained all topics and topic ids in the project. I understand that all topics are XML in Flare, but is there a way to get a list of all of the topics and their topic ids in one file. My developers use the XML file I generated from Robohelp as a way to hookup context sensitive help.

I found a way to get an XML file that lists all of the topics in the Table of Contents by compiling as a WebHelp target in Flare. The file name is TOC.xml, but when I develop multiple help files each file for the compiled project is also named TOC.xml and there is not an entry in the file for the project's name or compiled help file's name. In Robohelp, the XML file was named after the project so it was easy to work with.

[Richard Ferrell]

You could just create an header and Alias file, and give them the Header file so they know what topics are included and what to call

[mrsvolunteertoomuch]

I know that is the "standard" way of doing context sensitive help, however, there is nothing standard about the way the development team I am working with does this. They read in an XML file and then I assign the keys by knowing the topic url, topic id, and topic title through a custom window. They do this because they put a wrapper around the .chm file so it appears in a window that the user can add their own information to. Sort of how 3.1 hel p used to allow you to annotate help....

[Andrew]

I know that is the "standard" way of doing context sensitive help, however, there is nothing standard about the way the development team I am working with does this. They read in an XML file and then I assign the keys by knowing the topic url, topic id, and topic title through a custom window. They do this because they put a wrapper around the .chm file so it appears in a window that the user can add their own information to. Sort of how 3.1 hel p used to allow you to annotate help....

I'm curious...how did you accomplish this? It's something we've been struggling with for years -- trying to figure out how to create user-editable (or at least, user-annotatable) help.

[Richard Ferrell]

If you open the TOC file in your Project Organizer with the internal Text editor, it will show all of the locations of your files in your project. you may have to play with it to add the full URL, but it will get you going in the right direction

[mrsvolunteertoomuch]

Our development team is handling the way that the .chm file displays. They are developing in .NET and when the user presses F1, they display a non-standard help form (window) that has 3 tabs at the top, the help that I have assigned (by them reading in the xml file with all of the topics and me assigning the correct topic to the correct form) to the key for the form the user requested help from in the right pane and a table of contents that I also assign, sort of like a See Also (also accomplished through the XML file) on the first tab. The second tab is labeled Custom Help and the user can enter any information they want here (unlimited, the text is stored in an SQL database). The third tab is labeled Online Help and it offers the user additional methods they can receive help from my company: Ask Support a Question, Onine Forum, Product Knowledge Base, Web site link, etc. If the user wants to see the entire help file in its regular .chm format with the TOC and Index as I designed it in Flare, they press a button to display Entire Help and then it displays on top of the non-standard help form.

This method puts all of the work of attaching the help to the program on my shoulders. I am responsible for developing the help, creating the XML file, placing the XML file in a directory (that gets read in when I access Help from the program -- I get a fourth tab for Maintenance that the user does not see), assigning the topic to the key that is displaying from the form, assigning the See Also topics (that display in the left pane of the first tab), and checking in a file that gets created after I do all of the assigning. This file then is what is read to display the help to the end-user.

[Andrew]

Interesting approach! Ah, how I curse the day our development team decided to use keywords to create context-sensitive help (instead of header/alias files like, well, *everyone* else I've ever talked to in the industry).

[RamonS]

That is why the tech writer is to be the one deciding how help gets implemented, not some clueless developer. Developers typically pick solutions that are easy for them, not those that make sense or are easy for others.