DotNet Help and Dynamic Help

[Sarah]

Hi

I've been using Flare to produce PDFs and HTML Help (csh) outputs. However, in another project I want embedded dynamic help. What we have currently is a pane on the side of our application which users can open or close, and the help topics in it change according to where they are/what they do. I used to simply give the developer a set of uncompiled, loose html pages (made in FrontPage) for every release with the updates or new content.

Now that I'm producing the pdf etc from Flare I want to single source it and produce the html pages using the same content. But how do I go about providing this to the developers - what exactly would I give them? Do we need to use the MadCap Help viewer? Would I create and generate a dotnet target and give them that output? I don't want standalone help or an external viewer.

Thanks in advance for any help.

[RamonS]

As I understand it, you need the DotNet Help SDK for this. See this page:
http://www.madcapsoftware.com/downloads ... ables.aspx

You can download and install it, as far as I recall it has sample code in it. Documentation should also be included.

[Sarah]

Thanks.

But something before I get started - does our application have to be dotnet, to work with dotnet help? Because it's a powerbuilder application. If that's a problem is there some other way I can get around it, or would I have to revert to copying the content from flare to frontpage and making the html pages there, as before?

[NorthEast]

Since you previously displayed HTML pages (from FrontPage), then you could also build your help as WebHelp, and link directly to the HTML files in that.
You can just open the topic file directly, you don't need to open the WebHelp container with accordion and toolbar.

(The main drawback of this is that you cannot use Flare's CSH calls, i.e. make a call using an alias/value. You must have a link to the actual filename, which is less flexible.)

If you need the full WebHelp container, i.e. you want contents, search or toolbar; then you can also open WebHelp with the accordion pane hidden.

[Sarah]

Thanks - that sounds like a better alternative than going back to frontpage! But I'm still uncertain what I would give to the developer - the compiled webhelp output and the alias/header files only, and the header files would then enable him to link up the topics to the correct windows so only the topic itself shows to the user?

Furthermore - do you know, if it would be dynamic then - I've gotten the impression from flare documentation that the only way to get dynamic help is with dotnet, is that right?

[Sarah]

Oops, I missed what you wrote about CSH aliases. Ok, so I would have to maintain that completely separate from flare? For example, previously we just named all the html files after the window they belonged to, and the developer hooked them up accordingly.

[NorthEast]

Oops, I missed what you wrote about CSH aliases. Ok, so I would have to maintain that completely separate from flare? For example, previously we just named all the html files after the window they belonged to, and the developer hooked them up accordingly.

Nothing much would change, and you would link directly to the files in the same way as you did with your files from Frontpage. If you've used the same filenames, then only the path to the file might need to be changed, as the files in WebHelp will be inside a Content folder.

My point about CSH calls is really dependent on whether or not you want to include the WebHelp container (accordion pane and toolbar), or whether you just want to display the topic and nothing else.

If you don't want to use the WebHelp container at all, then you must link to the topic files directly, and would not use a Flare CSH call. So in effect, you're just by-passing the whole WebHelp container.

If you wanted to set up an alias file and use a Flare CSH call to open topics by an identifer/value, and not by their filenames, then be aware that using a CSH call would also display the WebHelp container. Therefore, you couldn't use a Flare CSH call if you didn't want the WebHelp container to be displayed.

[LTinker68]

If you wanted to set up an alias file and use a Flare CSH call to open topics by an identifer/value, and not by their filenames, then be aware that using a CSH call would also display the WebHelp container. Therefore, you couldn't use a Flare CSH call if you didn't want the WebHelp container to be displayed.

Is that strictly correct? I don't have Flare open at the moment, but I think there's an option in the skin to have the navigation hidden initially, so a CSH call should still open the help with the navigation hidden. That's why there are options to enable links at the top and/or bottom of the help that say "Open navigation pane" or something like.

[NorthEast]

If you wanted to set up an alias file and use a Flare CSH call to open topics by an identifer/value, and not by their filenames, then be aware that using a CSH call would also display the WebHelp container. Therefore, you couldn't use a Flare CSH call if you didn't want the WebHelp container to be displayed.

Is that strictly correct? I don't have Flare open at the moment, but I think there's an option in the skin to have the navigation hidden initially, so a CSH call should still open the help with the navigation hidden. That's why there are options to enable links at the top and/or bottom of the help that say "Open navigation pane" or something like.

Yep, I actually mentioned that in my first post - "...you can also open WebHelp with the accordion pane hidden".

If you enable Hide navigation pane on startup in the skin, only the accordion pane is hidden and the toolbar is still permanently visible. Therefore you couldn't use this option if you wanted a system that includes only the help topics and no elements of the WebHelp container.

[Sarah]

Hi

I just ran a test of the target with Hide Navigation Pane on Startup checked and yes, the toolbar is there. At the moment anyway, can't have any of that.
Just the topics - so if I hand over a normal webhelp output though, they'll be able to embed those pages into our software so they just show up by themselves, in the side of the window, as before? I'm having trouble understanding what will happen on the developer's side.

[LTinker68]

Did you set the toolbar height in the skin to 0px? Or maybe it has to be 1px. In any case, if memory serves, to hide the toolbar you have to shrink its height -- it's only the nav pane that you can actually set to be hidden.

[NorthEast]

Hi

I just ran a test of the target with Hide Navigation Pane on Startup checked and yes, the toolbar is there. At the moment anyway, can't have any of that.
Just the topics - so if I hand over a normal webhelp output though, they'll be able to embed those pages into our software so they just show up by themselves, in the side of the window, as before? I'm having trouble understanding what will happen on the developer's side.

On the developer's side, presumably there would be little (if any) change from before; they're simply displaying a web page, the web page is just produced using a different tool.

If you needed to use CSH calls, and don't want direct links to files, then there may be a way to hide the frames altogether. You might be able to reduce the size in the skin (as LTinker suggests), or you may be able to manually edit the frameset definition in the output (Default.htm) which sets the frame properties. I can't really offer much advice though, as it's not something I've tried or tested.

[alex]

Sarah, were you able to make this work? I think I may need to go down a similar path...

[Sarah]

Hi

this did work out fine for me. I just generate a webhelp target every time and the developer takes it from there using the individual pages in the output. Did you end up doing the same?

[alex]

Hi Sarah,

Thank you for your response! We have not yet tried this, but I will update this thread when we do. I'm hoping this method will work for us.

Thanks,
Alex

[mathanjiti]

yes, i agree with dev lee comment. I think this is good