I have a Visual Studio .NET (Visual Basic) application with context sensitive help produced by Help & Manual 8.
I have been using the .CHM approach for many years, and everything has worked smoothly. Now I am trying to switch to the new improved eWriter approach.
I've almost got it working, but just need some help please.
In my Visual Studio project I have "HelpProviders" on most of my forms. I set each's "HelpNamespace" to the .CHM file produced by Help & Manual. My .chm is called IMapsHelp.chm. My HelpProviders are called HelpProviderIMaps.
Then on my form I will set the HelpProviders settings to a topic in the .chm, as shown in attachment "Help Old.png". (The "HelpKeyword" is set to e.g. i_Securities.htm, where "i_Securities" is the TopicID of the relevant topic in my Help & Manual poject. The "HelpNavigator" is set to "Topic".)
This works.
Now, I have created a eWriter help file, iMapsHelp.ewriter, with the same content as the old .CHM. In my Visual Studio project I changed the "HelpNamespace" to refer to the ewriter file. I left the HelpKeyword and HelpNavigator as they were.
When I run the app, and open that form and push F1 nothing happens.
However if I change the "HelpNavigator" to either "Topic" or "TableOfContents" then the (correct) eWriter file does open and show, but it shows the first page of the ewriter "book", and does not open on the relevant topic.
I have tried various other settings for the "HelpKeyword", namely:
i_Securities.htm
i_Securities.html
index.html?i_Securities.htm
i_Securities
but none of these work.
So my question is:
How do you correctly specify a reference to a topic when using a HelpProvider in a Visual Studio app in conjunction with an eWriter file.
Regards
Reg Bust
eWriter and HelpProvider in Visual Studio .NET
Moderators: Alexander Halser, Tim Green
eWriter and HelpProvider in Visual Studio .NET
You do not have the required permissions to view the files attached to this post.
- Tim Green
- Site Admin
- Posts: 7819
- Joined: Mon Jun 24, 2002 9:11 am
- Location: Bruehl, Germany
- Contact:
Re: eWriter and HelpProvider in Visual Studio .NET
Hi Reg,
The whole system is different to CHM, it's not a drop-in replacement. What you are doing with eWriter is more like opening a Word document with Word than calling a CHM help file. You basically need to be doing a System.Diagnostics.Process.Start() on the Viewer app with the help file name as the argument.
See here for details of the basic syntax with standard skins:
https://www.helpandmanual.com/help/hm_w ... tions.html
In Premium Pack V3 and V4 eWriter skins it's the same, but without the index.html? prefix, as there you only need to call the topic file directly. Anchors are addressed with ?anchor=anchorname after the topic.html name.
The whole system is different to CHM, it's not a drop-in replacement. What you are doing with eWriter is more like opening a Word document with Word than calling a CHM help file. You basically need to be doing a System.Diagnostics.Process.Start() on the Viewer app with the help file name as the argument.
See here for details of the basic syntax with standard skins:
https://www.helpandmanual.com/help/hm_w ... tions.html
In Premium Pack V3 and V4 eWriter skins it's the same, but without the index.html? prefix, as there you only need to call the topic file directly. Anchors are addressed with ?anchor=anchorname after the topic.html name.
Regards,
Tim (EC Software Documentation & User Support)
Private support:
Please do not email or PM me with private support requests -- post to the forum directly.
Tim (EC Software Documentation & User Support)
Private support:
Please do not email or PM me with private support requests -- post to the forum directly.
Re: eWriter and HelpProvider in Visual Studio .NET
Thank you Tim.
This helps but only a little.
The good news: The following line of code works, when run from the form. It opens an eViewer window and shows the correct topic from the correct ewriter file:
The not so good news:
The common scenario on a form in a Windows form application developed with Visual Studio is that on each form there will be many components, such as buttons, grids and the form as a whole, each of which (or groups of which) are associated with a different help topic. The Visual Studio solution to this is its "HelpProvider" component. You put one of these on a form, and set it to reference a file with all the help topics. Then you associate any of the components on the form with the HelpProvider and specify which topic is displayed for that component.
VisualStudio takes care of "when the user has selected this component and pushes F1 then show the help topic specified for it". No further coding is required.
If one has to write code to identify which component is selected and then make explicit calls to eViewer.exe and specify the ewriter file and the help topic to show for each component (with hard-coding), that is not an acceptable solution. I can't imagine that any developer with a reasonable complex application would be prepared to do this.
As I see it, unless there is some way for eWriter files to work with the HelpProvider feature in Windows Forms in Visual Studio, then eWriter files aren't a realistic option for Visual Studio developers.
Or am I missing something?
What gives me hope is the fact that if I use the HelpProvider approach and specify the "HelpNamespace" of the HelpProvider as the ewriter file (and not eViewer.exe) that it actually opens and shows. The only issue is that it doesn't open on the right page.
I'm hoping that you could get some Visual Studio / Windows Form expert who knows the HelpProvider control well and can find some clever workaround to make it work with ewriter files. Your online help pages have a link to an article written by Rob Chandler (last updated in 2004!) that gives details on how to link HelpProviders and chm files. If you could provide a similar article for linking HelpProviders and ewriter files, I, and many other Visual Studio Windows Form developers, would be most grateful.
Regards
Reg Bust
This helps but only a little.
The good news: The following line of code works, when run from the form. It opens an eViewer window and shows the correct topic from the correct ewriter file:
Code: Select all
System.Diagnostics.Process.Start("eViewer.exe", "IMapsHelp.ewriter i_Securities_Form.htm")
The common scenario on a form in a Windows form application developed with Visual Studio is that on each form there will be many components, such as buttons, grids and the form as a whole, each of which (or groups of which) are associated with a different help topic. The Visual Studio solution to this is its "HelpProvider" component. You put one of these on a form, and set it to reference a file with all the help topics. Then you associate any of the components on the form with the HelpProvider and specify which topic is displayed for that component.
VisualStudio takes care of "when the user has selected this component and pushes F1 then show the help topic specified for it". No further coding is required.
If one has to write code to identify which component is selected and then make explicit calls to eViewer.exe and specify the ewriter file and the help topic to show for each component (with hard-coding), that is not an acceptable solution. I can't imagine that any developer with a reasonable complex application would be prepared to do this.
As I see it, unless there is some way for eWriter files to work with the HelpProvider feature in Windows Forms in Visual Studio, then eWriter files aren't a realistic option for Visual Studio developers.
Or am I missing something?
What gives me hope is the fact that if I use the HelpProvider approach and specify the "HelpNamespace" of the HelpProvider as the ewriter file (and not eViewer.exe) that it actually opens and shows. The only issue is that it doesn't open on the right page.
I'm hoping that you could get some Visual Studio / Windows Form expert who knows the HelpProvider control well and can find some clever workaround to make it work with ewriter files. Your online help pages have a link to an article written by Rob Chandler (last updated in 2004!) that gives details on how to link HelpProviders and chm files. If you could provide a similar article for linking HelpProviders and ewriter files, I, and many other Visual Studio Windows Form developers, would be most grateful.
Regards
Reg Bust
- Tim Green
- Site Admin
- Posts: 7819
- Joined: Mon Jun 24, 2002 9:11 am
- Location: Bruehl, Germany
- Contact:
Re: eWriter and HelpProvider in Visual Studio .NET
Hi Reg,
I'm afraid we haven't that much experience with this component in .NET -- Help+Manual is programmed in Delphi and I use .NET for utilities but I've never used the HelpProvider methods beyond their standard overloads -- so it would be best to check this with someone who's actually done some deeper development work with those methods. We've put it on the ToDo list for further investigation but I'm afraid a lot of other things have priority at the moment.

I'm afraid we haven't that much experience with this component in .NET -- Help+Manual is programmed in Delphi and I use .NET for utilities but I've never used the HelpProvider methods beyond their standard overloads -- so it would be best to check this with someone who's actually done some deeper development work with those methods. We've put it on the ToDo list for further investigation but I'm afraid a lot of other things have priority at the moment.
Given that scenario, which I completely understand, I'd recommend staying with CHM for the time being.The common scenario on a form in a Windows form application developed with Visual Studio is that on each form there will be many components, such as buttons, grids and the form as a whole, each of which (or groups of which) are associated with a different help topic. The Visual Studio solution to this is its "HelpProvider" component. You put one of these on a form, and set it to reference a file with all the help topics. Then you associate any of the components on the form with the HelpProvider and specify which topic is displayed for that component.
Regards,
Tim (EC Software Documentation & User Support)
Private support:
Please do not email or PM me with private support requests -- post to the forum directly.
Tim (EC Software Documentation & User Support)
Private support:
Please do not email or PM me with private support requests -- post to the forum directly.