Context-sensitive WebHelp for a C# application

[Guest]

Hi,
We need to provide context-sensitive WebHelp for a C# application. We currently use RoboHelp X5. I noticed that the RoboHelp online Help provides the function calls and other information from a C++ perspective.
Would anyone be able to provide more information?
Or would our need mandate a move to RoboHelp Office Pro for .NET?

Thanks for your help.

[RoboWizard]

Hi CSH_try and welcome to our community

I don't see any pressing need to leap to buying RoboHelp Office Pro for Dot Net. As I understand it, all it really offers is some extra examples of linking things. But then again, maybe that's just the push you need? I believe it also costs about $1,000 more than standard RoboHelp Office. This is because of the RoboEngine component. So there's another consideration. Are you planning on using RoboEngine? That will add a whole new wrinkle to the mix.

As I understand it, you can connect using standard WebHelp output.

Cheers... Rick

[MergeThis]

No, there's no need for the Pro product.

Just have your developers call the URL for the topic. Ex: A form named UserMainFrm would be looking for a topic called UserMainFrm.htm. Individual controls on that form would also look for their names, but default to the form name if not found. This allows you the flexibility to go more granular in the CSH help whenever you like, without having to bother with the developers again.

If you're running a merged Webhelp output, create a comma-separated, pseudo-alias file (we call ours formpath.txt), which only lists the form name and its path ( ex: UserMainFrm.htm, mergedProjects/userhelp_project).

And, of course, all the calls have to go through the start page (common practice is index.htm).


Good luck,
Leon

[Guest]

Hi Rick and Leon,
Thanks for the replies and the friendly welcome.

Appreciate the help.

Glad to hear that there would be no pressing need to get RoboHelp Pro for .NET. The cost-factor is a huge limitation. As of now, we also don’t intend to deliver Help as a WebService, and will not be deriving data from usage patters…and will not require RoboEngine. So we hope to continue to use RoboHelp HTML X5.

I still have some queries, however. Just being a bit verbose here so that its more clear and reduces “back and forthing”!

What we are planning to do is to use the mergedProjects feature of WebHelp.

From the context-sensitive aspect we will make sure that the BSSCDefault.h file in the mergedProjects folder of the output has all the map_ids of individual child projects, etc.

Ours is a C# application, and a Help button on each form should bring up the correct Htm file within the WebHelp tri-pane view. Individual fields of a form would be described on the corresponding Htm page, and as of now we don’t want separate Ids for individual controls/fields.
We want to be sure that we provide accurate info to our developers who will make those calls to our WebHelp help files.
I figured that they would have these options:

Option 1.
Call the particular page that is part of our WebHelp by using
< a h re f="cs hweb help/index.htm ?#mergedProjects /child_project1 /topicX. htm" target="_ new" > or X:/help folder/index. htm# mergedprojects/child_project1/topicX.htm

Option 2.
Provide the RoboHelp_CSH.js to dev. The call they would use would be:
function RH_ShowHelp(hParent, a_pszHelpFile, uCommand, dwData)
where dwData and the Map_ids would determine which HTM file is called from our WebHelp.

Option 3
The Microsoft site provides info on using the ShowHelp method for a C# app, ( http://msdn.microsoft.com/library/default.asp?url=/library/en-us/cpref/html/frlrfSystemWindowsFormsH...

Query A: would the info provided above work for a context-sensitive merged WebHelp project?

RoboHelp Online Help documents the function defined in the file RoboHelp_CSH.h. This info is documented from a C++ perspective.

Query B: What would need to be done from the C# perspective to bring up the context-sensitive/mapped HTM file within the Tri-pane view of the merged WebHelp output.

Would you be provide more info?

Thanks.. appreciate your patience in helping newbies like me!

[MergeThis]

Did you have a chance to read my previous message? The second and third paragraphs address your concerns about merged Webhelp and the tri-pane issue.

As to which specific method used by the developers, that's on them.


Good luck,
Leon

[Guest]

Hi,
Thanks for your reply.

Yes, I did go through your previous message. In our case, we need to provide dev with options.

So I guess Option 1 (inclusive of your suggestion) and Option 2 would be Ok.

Only with option 3, and the RoboHelp_CSH.h file, the documentation available was from a C++ perspective, so I just wondered how things would be different from a C# perspective.
Thanks!

[catamaran]

CSH_try,

We're also working on csh/C# and I wanted to check with you. If you tried option 3, did it work out?

Thanks,
Linda

[Guest]

Hi Linda,
Apologies for not having replied earlier.. was on a hiatus for a bit!...just been bogged down with other things.
No, we did not proceed with investigating option 3.
We decided to stick with calling the htm file thru the URL...
All the best with your investigation.
Do keep us posted.

[catamaran]

Hi CSH_try,

Thank you for taking the time to write - we know how bogged down goes! A deadline put our research aside for a while, but it looms. I would appreciate hearing the following about your experience.

1) What specifically made you select the URL method over mapping?
2) For csh/ C#, did using the URL method require any special developer actions or files, other than the simple typical file that calls the topic/per page (for an earlier version, we called ours index.asp, and it did just that).

Luckily, our csh is planned for next summer, but it will be huge, and the more we can do now, the better.

Cheers,
Linda

[Guest]

Hi Linda,
Again a delayed response.. apologies. But hope this helps.
The developers had trouble using the RH javascript CS calls and context IDs. The developers are now using the URL method to call a window that opens the WebHelp project (the window displaying the WebHelp is a window with WebBrowser controls from the C# app)
(We call the context-sensitive help page via the index.htm page)
Hope this helps.

[MergeThis]

And by the way, if you're using a merged WebHelp project, you can provide a CSV .txt file that identifies the [project] folder where the topic resides in relation to the index.htm start page.

For example, our formpath.txt file reads:

AcctMainFrm, mergedProjects\menuhelp
AcctRepriceFrm, mergedProjects\menuhelp
etc.


Good luck,
Leon

[catamaran]

Thanks, Leon. That does help, and I appreciate your replies. Knowing that your developers had problems with the calls gives us a good reason for not using them. There will be enough complexity anyway, as the product and engineering methods are changing significantly. The method you described is the way we did it in the distant past, and that's what we'll do this time too.

Linda

[HKabaker]

CSH_try,

What happens when . . .
1. You start the C# application and click the Help link.
2. Does the help window come into focus displaying the correct topic?
3. Do not close the help window.
4. Refocus the C# application and navigate to a different screen.
5. Click Help on the new page.
6. Does the help window . . .
(a) come into focus . . .
(b) displaying the correct topic?

7. Repeat 3 through 6 and go to 8.
8. Does it sometimes require a double-click to get there?
9. Was the answer to number 6 always "Yes"?

Many of us will be very interested in your results.

Thanks

Harvey