RoboHelp for .NET

[CKentCarle]

Can anyone help me out with the following question? We already own one version of RoboHelp .Net, but will be having a second person helping develop content. Do we need a second full version of the RoboHellp .Net version, or can we purchase the RoboHelp Pro version, and then when compiling for .Net, do so just in the .NET version?

[Captiv8r]

Hi CKentCarle and welcome to our community

From what I understand, the only real difference between the normal version and the "Dot Net" version of RoboHelp, is that with the "Dot Net" version, you get some extra examples. From the standpoint of what you publish, I don't believe there is a difference. So unless others know different, I'm guessing you would be fine going with the less expensive second copy.

Cheers... Rick

[CKentCarle]

Thanks for the quick reply Rick!

[Peter Grainge]

My understanding from an eminent authority is that you only need the Dot Net version if the help is being run as a service. At least I believe it is the help rather than the linked application. That is something your developers will have to tell you. If they can clarify whether the "being run as a service" applies to the application or the help or both, it would be really helpful if you could post that here. Helps us help the next person along.

[IR-PROGNOSIS]

If you intend to use context sensitive help my understanding is that .NET only supports context strings where standard Robohelp only supports Map Ids. I have been unable to find a way to make standard Robohelp create context sensitve help for .NET applications and I cannot get any repsonse from Robohelp as to whether Robohelp .NET allows context strings.

[CKentCarle]

Thanks for the reply, I am going to keep trying to get a hold of someone at Adobe, but the wait times are unbearable. I appreciate your responses. If I get a response from Adobe, I will make sure it is posted.

[MergeThis]

Some of these replies don't quite hit the mark.

We create Webhelp for a .NET application. Context-sensitive calls are made to the URL (the MainUserForm window looks for the MainUserForm.htm topic file, etc.). Since it's a merged Webhelp project, the application looks into our form_path.txt ASCII file to see in which project folder to find the topic (MainUserForm, mergedProjects\mainhelp).

We have seen no need to use RoboHelp .NET or the RoboEngine. Just good ol' RoboHTML.


Good luck,
Leon

[ajperrins]

Leon:

So what is the advantage of using the .NET service handled by the RoboEngine?

After looking through the API (about 4 source files), I've found the following:

ShowEnterpriseHelp() - the ".NET " implementaion, is used when your URL ends in .dll, which will be handled by the RoboEngineService proxy, calling the RoboEngine ISAPI's web-service, implemented in .NET 1.0. The main advantage seems to be that a CRoboEngineWindow type is interpreted from the returned XML, giving the help-author the ability to set up how the window will look. Is that right?

ShowWebHelp() - will be used when your URL ends in .htm, and will open a web browser (in process) using COM interop with the provided URL (this seems to be the way you're suggesting...?) Though, we're using .NET 2.0, and we could/should probably use the built-in framework WebBrowser control now.

Thanks for any feedback ! ! !

P.S. I have not been able to publish my help-author's help to the .NET RoboEngine yet anyway! so I might _have to_ use the WebHelp approach!

[CKentCarle]

Thanks Leon, I appreciate everyone's feedback, but it looks as if you are heading down the direction I am looking for, I will pass this information on to our developers.

[MergeThis]

The RoboEngine must be installed by your IT peeps on a server, after which you can generate Webhelp Pro to it.

The added features are:

1. Natural language search for the end users.
2. Usage tracking for the client's IT peeps.

If you don't feel the need for either of those features, store the RoboEngine CD and the .NET software on the nearest convenient shelf, and generate plain ol' Webhelp.


Good luck,
Leon