Has Madcap abandoned Dot Net Help?

[nsemple]

I now have Madcap Flare Version 6, and find myself as I have for the past several releases of Flare, totally frustrated with the lack of development effort that has been given by Madcap to Dot Net Help.

This output type, which they once touted, has been consistently neglected from release to release as the Madcap developers work on other things.

Despite forum postings that clearly show the interest and frustration of potential Dot Net Help users (see topics such as "Compiling DotNetHelp into a single file" - viewed more than 2,500 times by customers and "Whose Help is this anyway?" - viewed more than 15,500 times by customers), the Dot Net customer base seems to have been totally ignored by MadCap.

If there are enhancements to Dot Net Help in Flare Version 6, can you please let me know what they are? I've yet to find any.

We'd love to use this functionality, but need to see some product enhancements.

We believe MadCap should spend some time fixing technology such as this that they already have in place rather than adding to their product suite.

You get tired of submitting enhancement requests and logging bugs when you feel like you're just being ignored...

[RamonS]

I'm speculating here, but I think it is a chicken and egg problem. I am sure it would be higher on MadCap's to do list if more customers would use it, but many don't use it because of the design flaws and lack of functionality. Aside from that, it is another proprietary format that requires installation of a special viewer on the client systems. It isn't an ideal help candidate to begin with.

[Mike Hamilton]

Hi Nancy,

A lot of work was done specifically on DotNet Help in the V6 release. DotNet Help has not been neglected at all. There weren’t many changes in the V5 time frame, but there were major updates in V4 and now major changes in V6. I’m not sure that warrants the comment that it has been “neglected version after version”.

Your post cites two previous threads, one is "Compiling DotNetHelp into a single file" and the other is “Whose Help is this anyway?".

To the first, “Compiling DotNetHelp into a single file”, we would love to do that, however, you are then entering a state where the operating system sees the DotNet Help file as an executable. Once that threshold is crossed you enter a whole new world of security problems where authors have to purchase security certificates (which have to be renewed yearly), files have to be registered on the installed machine before they will run (requiring special installers to be written), etc. We are not against a single file deliverable version, however our research has found that most doc teams don’t have the resources or the desire to jump through all of the additional security hoops that would be required.

To the “Whose Help is this anyway?” thread, well that thread was almost the entire road map for the changes that occurred in the V6 work. The items mentioned in that thread include:
• Why would we want menus linking to the MadCap site or forums in our help? – removed for V6
• Why would we want the MadCap logo in the title bar of our help? – removed for V6
• Why would we want the MadCap logo splash screen to appear? – Now in V6 the splash screen is only visible when you double click the HelpViewer.exe file. Launching it any other way (double-click a .mchelp file, use the SDK for external window, use the SDK for embedded) now suppresses the splash screen logo.
• Why would we want update messages from MadCap in our help? – removed for V6
• Why do my users get prompts to install some database? – removed for V6
• I want multiple CSH calls to reuse the same DotNet Help window – modified in V6 so you can now have a single CSH window or multiple CSH windows depending on need. If you launch the Help Viewer from the command line with the path to the Help system and a CSH ID, we don’t open separate windows each time. If you only provide the path to the Help system, we open separate windows.

I hope that this information helps,

[RamonS]

Thanks for sharing this. I admit I haven't looked at DotNetHelp for a while (mainly due to lack of need), but once I have some time to spare again I like to pitch DotNetHelp to the local DotNet user group that has its meetings at my work. My experience is that developers are often totally unaware of what help is all about and showcasing Flare as DotNet app and DotNetHelp may give some insight. I think now DotNetHelp is in a shape that makes it more applicable and presentable.

[nsemple]

Hi Mike,

Thanks for responding.

Great news that you are continuing to make enhancements to your DotNet Help.

Unless I am mistaken, I do not see anything in the Flare Version 6 Help topic titled "What's New in This Version" regarding changes to DotNet Help in Version 6. I have also scoured the Version 6 Flare Help files to see if there is any additional information for working with DotNet Help and cannot find anything. Is there information in your Help system somewhere that describes specifically what changes have been to DotNet Help made in Version 6?

For the cosmetic changes to the viewer that you mention, such as removing the Madcap logo and product name from the titlebar, can you please tell me where in the interface I can change these items? When I open our skin file in Flare, there is a "caption" setting on the General tab that enables me to enter text for the Help project title. However, this caption only seems to get picked up for other output types such as WebHelp and HTML Help. The text "Madcap Flare V6" remains in the titlebar for the DotNet Help viewer regardless of any changes that I make in this "Caption" text box. The Madcap logo also continues to appear in the title bar of the DotNet Help viewer and I cannot figure out where the setting is to get rid of it. When I open the Styles tab for the skin file and set the logo to "none", it does nothing. The logo still appears. Where do I indicate that I do not want the Madcap logo and Madcap Flare text in the titlebar of the DotNet Help viewer for version 6? I can't figure out how to change the titlebar and I can't find any information about this in your Help system.

If you have not already done so, as you continue to work on DotNet Help, will you be addressing these items:

- Can you localize the DotNet Help viewer in other languages?
- Can you change the skin for DotNet Help output?
- Can you customize the toolbar in the DotNet Help viewer (removing/adding toolbar buttons, adding text inside the QuickSearch text box, etc)?
- Are there any plans to pack the output content into some type of container file (such as a zip file) that can be used by the client with the possibility to unpack the zip in real-time to open a requested file?
- Are there plans to address the issues in the forum topic titled "Issues preventing DotNet Help Rollout"?

I am not sure who you have been talking to when you state "our research has found that most doc teams don’t have the resources or the desire to jump through all of the additional security hoops that would be required" to provide a single file deliverable version.

We have been hoping for quite some time that you would offer a single file DotNet Help deliverable solution and think that others out there are interested as well (again, forum topics such as "Compiling DotNetHelp into a single file" - viewed more than 2,500 times by customers).

The overhead and maintenance dealing with thousands of files (in a variety of languages) versus dealing with a single output file is huge for us as authors, for our development teams, and for our customers.

We long for the days of chm files that could be viewed over the network, and we are hoping that you will work toward a solution that will enable us to provide customers with some type of single compiled DotNet Help project file.

If possible, we would like this single compiled file to be viewable over a network (one server on which the Help resides, many clients accessing the Help content on the server).

Regards,

Nancy

[adlangx]

Hey Nancy,

I can at least answer your question about changing the icon. This is in the "Customizing the Dot Net Viewer...." thread, but I will repost it here for simplicity:

adlangx wrote:There is now an overload in the HelpViewerEmbeddedClient class that allows you to pass in an string and an icon into the constructor. The string and icon that you pass in are then used in the help form header in place of the Madcap icon and "My Help" string.



alex wrote: Please post how you do this. Thanks!


adlangx wrote:

-Add the Icon file that you wish to use into the Resources area of your project. (Here is a quick description of how to do it http://visualbasic.about.com/od/usingvb ... 090117.htm )

-Then make your call to create the viewer like this:

HelpViewerEmbeddedClient(<HelpTitleString>, My.Resources.<YourResourceName>)

In order to implement the help we also compressed the help files into a zipped package that downloads to the client fairly quickly. Not an ideal solution, but it works.

Let me know if you have any questions.

[nsemple]

Thanks for sharing this information.

I'm a bit confused though. Mike Hamilton's email led me to believe that this functionality was included in the interface for Flare 6. Your information seems to be a workaround to get functionality to work that is not included as an option in the interface.

Are you saying that there is no straightforward option on the interface in Flare 6.0 to specify the titlebar text and logo that you want to include in the DotNet Help viewer?

[RamonS]

The change can be implemented through the use of the SDK.