This content has been marked as final. Show 9 replies
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.
Thanks for the quick reply Rick!
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.
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.
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.
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.
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!
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.