Whose help is this anyway?

[MikeKatz]

The people have spoken and MadCap has listened! :0)

The plan right now is to alter the DotNet Help viewer to make it more in line with the requests we have received. One of the biggest problems is the timing. All of our dev resources are turning and burning to get Flare version 4 out so this solution will be for that release {/bracing for stone and bottle throwing}. The good news is that we will try and have this new behavior in the Flare version 4 beta refresh that is coming out next week so that people will be able to test and provide feedback on the implementation.

What will the new behavior be?

There are three common methods to launch a DotNet Help system:
1. In a context sensitive manner from the application.
2. By double clicking an icon.
3. By selecting it from the Start>Programs> menu in Windows.

The existing Flare 4 beta has already turned the splash screen off for example 1 calls above (context sensitive links). For next week’s beta refresh we plan to also disable the splash screen for calls made through example 2 (clicking an icon). The only time that the splash screen will now appear is if someone launches it from the Start menu programs group.

Thanks Mike!

[BL_N]

Wonderful news, indeed! Thank you for the update!!

[forfear]

amazingly responsive. all the best with the v4 releases mateys....tis crunch time in software dev terms.

[mikejp]

I started this thread (way longer ago than I care to remember) fully expecting to told that I was too dumb/tired that evening to find the correct options, rather than - as far as I can tell -start the first and only really acrimonious discussion MadCap and its user-base have had. Here's hoping it's also the last! I reckon we've all won here, including and especially MadCap.

Sadly, the company I was working for then chose to revert to R####### (for a wholely unrelated reason) so won't benefit. And the company I work for now uses - you guessed it - so I won't either, at least not in the immediately foreseeable future. That aside, I still keep a watching brief on MadCap, and will evaluate Flare 4 on release (rather than its beta).

So, I guess this may be my last post for a while.

Fare well, bretherin

[forfear]

hi mike nice to hear from you.. this could indeed be the longest running thread on the forums.

i guess its the bundlin that did it isn't it? oh well...anyway strong products coming up...till the next job i guess.

[RamonS]

Mike, you just need to pick your jobs more wisely.

[forfear]

Mike, you just need to pick your jobs more wisely.

hahaha....well, that's another way around it.

[brettzalkan]

Thrilled to hear about the attention the dotNet View has gotten. Does it remain a requirement that the Help Viewer must still appear in the All Programs menu when our software is redistributed? Are we now able to suppress this behavior? If not officially, is there a hack?

Thanks,

Brett

[RamonS]

Typically, you can instruct the installer script to do a post-install cleanup which would include ditching that entry from the Start menu. I also do not know which registry entries the viewer needs and if there are any dlls that need registering. You could try things out a bit and see what you need to do besides writing the files that the help viewer needs. It could very well be that you don't need to run the installer from MadCap, but can roll it into your own.

[tbean]

If I understand Mike's post from July 3rd correctly, then the unwanted behavior will largely be gone IF you are using Flare 4 and DotNet Help Viewer 4. What if you're still using 3.1?

...
The plan right now is to alter the DotNet Help viewer to make it more in line with the requests we have received. One of the biggest problems is the timing. All of our dev resources are turning and burning to get Flare version 4 out so this solution will be for that release {/bracing for stone and bottle throwing}. The good news is that we will try and have this new behavior in the Flare version 4 beta refresh that is coming out next week so that people will be able to test and provide feedback on the implementation.
...

[LTinker68]

If I understand Mike's post from July 3rd correctly, then the unwanted behavior will largely be gone IF you are using Flare 4 and DotNet Help Viewer 4. What if you're still using 3.1?

You'll have to upgrade. If you have a maintenance contract then you would have gotten the upgrade for free.

[tbean]

Well, phooey. Upgrading is not an option, at least not today.

If it's not possible to build this into the UI as a 3.1 bug fix, then is it possible for MadCap to publish directions on how to make the modifications manually? I know that Lisa posted an older-version workaround (back in 2/2007, on page 4) and that Marc had some success with it. Is that workaround applicable to 3.1?

Thanks --
Tracey

[Richard Ferrell]

That option would still work even in V3.1

It not possible for us to patch the 3.1 SDK to allow this feature, But the SDK for Flare V4, does remove the Caption and startup image.

[tbean]

Thanks, Richard.

[brettzalkan]

It not possible for us to patch the 3.1 SDK to allow this feature, But the SDK for Flare V4, does remove the Caption and startup image.

There's a Flare SDK? Does this just refer to the info for hooking up context-sensitive Help, or is there something more substantial?

[LTinker68]

There's a Flare SDK? Does this just refer to the info for hooking up context-sensitive Help, or is there something more substantial?

It's for hooking DotNet Help to your app. http://www.madcapsoftware.com/downloads ... ables.aspx

[Richard Ferrell]

the SDK is just for Dot Net Help, If you need help CSH help on other outputs see the following Knowledge base article.

http://kb.madcapsoftware.com/default_csh.htm#CSH1005F

[Aaron Peronto]

Typically, you can instruct the installer script to do a post-install cleanup which would include ditching that entry from the Start menu.

We are including the DotNetHelpViewer merge module in our deployment project for our application.
Is there a way to get rid of the desktop MadCap icon as well as the start/programs menu items?
I am trying to find some sort of reference for adding a post-install custom action to our deployment project (or something similar) that will allow me to remove these icons from the user's desktop when we have completed our installation steps.

Also, thanks for making the changes to the 4.0 Viewer. However, I do get a pop-up when I first run the new viewer on the client's machine that says something about getting faster searches by installing some DB tool. Is there a way to prevent this message from coming up or is this just something they will have to see once and dismiss it? Not a huge deal but I hate confusing the end users by asking them these sorts of questions that they really should not be making decisions about.

Thanks.
Aaron Peronto

[Richard Ferrell]

I would log this as a feature request

https://www.madcapsoftware.com/bugs/sub ... lare&v=4.0

[Tom]

Hi,
On Tue Nov 28, 2006 10:32 am, 'mikejp' started this topic. And now (december 2008), there is a new version of the DotNet Viewer (4.1). And clearly the marketing of MadCap refuses absolutely to take the customers serious.
There are three serious points:

- we are software-developers and our application is administrative software for company's. So why the hell must we bother our users with your compelling screen for updates (like Adobe, but there we are talking about general uasage of the PDF-reader and a general used fileformat.... A helpfile is used in the context of the product of another company). They will have to install them at your site and at your command (because chosing 'No' works only for one instance of running the viewer). So "who's help is it anyway"?????? Why do you as a company take over the version control for thomething that should be helpful for de products of our company??? Don't we have any say in this???

- Starting het help is much to slow for a customer needing quick support encountering problems with our application. They are not in the mood to wait for your Splash logo.
And of course we buy MadCap as third party product to be helpful for our customers, but showing the name of a third company everytime our users need help is not our policy (whose 'software is it anyway''???).

- The name and logo in the menu.... Well.... more than enough has been said. (whose helpfile is it anyway???).

Now with version 4.1 of the viewer en no single progress at all, and no sign of any understanding of your customers, the use of your product in context and the market for MadCap Flare, we lost all hopes and decided to go back to HTML (yes...., in RoboHelp).

[RamonS]

And RoboHelp puts less advertising in their HTML Help? I agree that ideally the DotNet Viewer should be at least configurable so that the advertisement can be turned off or reduced to a one liner in the about box.
In regards to update prompts, you get those from any browser or 3rd party product that can run as a stand-alone as well. While I don't like it it is common practice in the software industry and compared to Apple's forced updates that always install all this iTunes garbage the MadCap prompts are considerably easy going.
The slow start is clearly a DotNet runtime issue. Every single DotNet desktop app I used so far is a slow starter, typically due to the sluggish runtime performance and / or the runtime compile that is going on (MSSQL Management Studio is a nice and annoying example). Sure, when you compare it to the CHM Viewer from Microsoft there is a huge difference, but the CHM Viewer is compiled to machine code and does not get interpreted like the DotNet stuff. While I understand your frustration with that you are barking up the wrong tree. Call Microsoft and tell them to make better platforms. One might blame MadCap for picking DotNet as their development platform, but there aren't many other alternatives for making a product of this scale, maybe Delphi, but good luck finding capable Delphi developers.

[Richard Ferrell]

The Splash logo has been removed from Flare V4.1, When you make the call from the application, you can disable this.