IE Security update wreaks havoc still!

[Dick_Rosenblatt]

Last June I sent Microsoft support the following e-mail, to which I got a feel-good, sympathetic reply, but no patch has ever been issued as far as I know:

"My company developed and maintains custom software for nine DoD, DA and other federal agencies and the subordinate organizations for each. Each client organization accesses the software via its own web server we set up and maintain. There are several hundred individual users overall.

"We developed online help using Robohelp HTML. The introduction of Microsoft security update 896358 has rendered the online help useless!. This is tantamount to locking the barn while shooting all the horses. The "workarounds" suggested in your technical bulletins are totally impractical for intranets with large numbers of users. Microsoft has GOT to QUICKLY develop a patch that can be applied at the server level."

My question to Adobe is - Can't you apply some muscle to Microsoft to fix this problem?

Dick Rosenblatt

[johnmccallum]

Dick,

Mind if I get on a soapbox and editorialize a bit?

Unfortunately, no amount of muscle from Adobe will change things at Microsoft. With Windows being the most vulnerable operating system ever conceived, Microsoft takes their security measures very seriously. Since WebHelp exists to provide online help over networks, the fact that your .chm files no longer can will generally be dismissed as irrelevant. That's the sad truth of the matter. RoboHelp has been pushing WebHelp since version 9 and Microsoft has been ignoring compiled help for even longer. To me, that makes .chm technology stable and desirable.

I agree Microsoft's "workarounds" are absurd but there are other ways to circumvent the problem, namely WebHelp or having all users download the .chm to their local drive.

John

[Dick_Rosenblatt]

So, the lesson is, "When the 800 lb gorilla decides to eat your lunch, offer your shirt as a napkin." OK, so be it.

A couple of points - the second being another rant from me

The workaround I used is the second one you suggested - download to the local drive; this is cumbersome at best, but better than nothing.

Now as to your remark about Robohelp pushing web help since version 9, it would have been very helpful if Macromedia/Adobe had alerted registered authors to the problem & had offered solutions - such as converting HTML Help to WebHelp (a tricky task, I'm told). Maybe they have, but I've subscribed to the Macromedia (now Adobe) news letter for a couple of years, and, to the best of my knowledge, have never seen anything there or (anywhere else) urging conversion from HTML to WebHelp because of problems with Windows.

While I ran into the problem in June 95, a post from IainCliffe (04/24/2006 11:41:53) indicates he just now ran into it. One of the two replies he got suggested he run some diagnostic to see if his .chm files were "up to snuff and matched." The other, from me, included a copy of my post that you replied to and the workaround download instructions I sent to our users.

How many other authors might have been saved a lot of grief with a few timely words from the vendor?

Dick

[johnmccallum]

Dick,

Of course, it would be good if the right hand knew what the left hand was doing, but unfortunately we don't. Microsoft will react to any perceived security threat and if anyone could have foreseen it, the loophole wouldn't have been there. This is simply the price we pay for having an operating system with tentacles extending into everything we do. Do the benefits still outweigh the costs? That's a moot point.

I've never worked with WebHelp, as I have the luxury of working in a highly regulated environment, but with RH touting Single Source layouts I'd think that the CHM to WebHelp conversion is getting easier and easier.

I don't mean to denigrate your concerns but I think I responded because I suffer from the exact opposite frustration - since version 8 (1999), RH has put all of it's efforts into WebHelp and has failed to fix a few fundamental weaknesses in compiled help.

John

[Dick_Rosenblatt]

John,

Well, as they say, "If rape is inevitable ... ."

I'm going to carefully check out the conversion process & then report to the WebHelp forum as a humble supplicant.

Thanks for your insights and good humor.

Dick

[Captiv8r]

Hi all

I'd just like to weigh in on the comment made about the process of creating WebHelp being a somewhat "tricky" task. Where does this idea come from? WebHelp is easy. You pretty much just generate the output and run with it. If you are willing to toss out some specifics, I'll be happy to see if these can be addressed.

I also would have to agree that it has been a frustrating process for me to see development in some areas while the bugs remain in others. (think merged .CHM files for one - Easily linking to secondary windows for another)

Anyhoo... My two cents worth... Rick

[Dick_Rosenblatt]

Hi, Rick

Glad to hear you think it's an easy process. But I've got to see for myself.

You asked for specifics. Since I've just begun looking seriously into WebHelp, I have only a couple (granted it may be because I'm a newbie there):

After changing a project's primary source from HTML help to WebHelp, I tried to tailor a WebHelp window to the dimensions and position of the HTML window; it wouldn't work - WebHelp covered the entire screen.

I couldn't find a way to let the user print the text in the right hand help pane.

Our users (used to be able to) display HTML help by clicking a button on the application's task bar. Can I do this with WebHelp?

Thanks for your interest.

Dick

[Peter Grainge]

Dick

Only a developer using an API can determine a window size, I believe. Otherwise it opens however the user wants their browser window to open, not unreasonable.

As to printing, they simply use the browser's print function. That might not print the topic though if they have not clicked in it. To overcome that, you can add a Print button. There is something in Snippets on my site covering that and I am sure Rick's Tips and Tricks that you can download from his site will cover it. There's a link to his site in his earlier reply.

I have waded in as I expect Rick is teaching in class so it will be a while before he is free.

[Guest]

We tried converting from CHM to WebHelp last november. It was really easy and everything worked well, but two problems had me put the conversion on hold.

First, at least on our computers, WebHelp is a lot slower. Everything takes more time (except the initial opening of the project of course) and since our users open the project first thing in the morning and leave it open until the day is over, they found WebHelp way too slow.

And second, which was our major concern, is that the WebHelp search is nowhere as good as the HTML Help search. All our projects (37 projects, 15 000 topics if I remember correctly) are in French, and we've seen a lot of words that we couldn't even use to search topics (they just aren't indexed I think). And our users like the Advanced Search functions provided in HTML Help (search previous results, using operators, using quotes, using *, etc.).

So we kept using HTML Help, but since we've always been having problems with links from one project to another (works but depends on MS patches...) and opening those links in pop-ups, we've implanted a "temporary" solution where all of our projects are available in both CHM and WebHelp. Instead of linking from CHM A to CHM B, we link from CHM A to WebHelp B, and so on. It's transparent for the user, and it has worked fine for the past 4-5 months.

But I'm always open to better and long-term suggestions ! : )

[Dick_Rosenblatt]

Good to hear it's working for you, but I've got a severe problem with WebHelp that I hope is due to my ignorance & not a deficiency in the application. Let me explain...

We use HTML Help as real-time performance support for financial analyst users of a fairly sophisticated resource management system. In a nutshell, the support consists of procedural steps for each user task and subtask. By following the steps, the user carries out the task; when the last step is completed, so is the task. Users can invoke and dismiss the help at their discretion.

The help is presented in a narrow window at the right side of the screen and is always on top. The window has two panes - the left contains the TOC, index, or search whle the right pane contains the topic. If the user wants to hide the left pane, the topic pane retains its original width. It obscures a bit of the application screen, but our users say this is easy to adjust for.

As far as I can tell, WebHelp will not do this. You can't keep the help on top and if you hide the left pane, the topic pane expands to fill the entire help window space. What's more, while HTML provides a button to print the topic, WebHelp doesn't.

These differences, while appearing minor, severly weakens the convenience of using our Help. Hopefully, I'm wrong about this & someone can tell me how to tweak the WebHelp window to do what I want.

Dick

[RoboWizard]

Hi Dick

Indeed I'm in the throes of a Captivate class that has seen its share of issues related to security. Ick!

Now for your points.

The help is presented in a narrow window at the right side of the screen and is always on top. The window has two panes - the left contains the TOC, index, or search whle the right pane contains the topic. If the user wants to hide the left pane, the topic pane retains its original width. It obscures a bit of the application screen, but our users say this is easy to adjust for.

As far as I can tell, WebHelp will not do this. You can't keep the help on top and if you hide the left pane, the topic pane expands to fill the entire help window space. What's more, while HTML provides a button to print the topic, WebHelp doesn't.

Indeed, the end user can hide the Navigation pane and what happens is that the topic does indeed simply consume the newly available space. So you are absolutely correct on that one. You are also correct in the bit about WebHelp being unable to use the "always on top" property. Well, you *CAN* accomplish it to a certain degree, but what results is something very frustrating for the end user, as WebHelp constantly steals focus from whatever application needs it.

However, you do have the ability to add a print button to the main toolbar of your skinned WebHelp system that will print the displayed topic for the user. I've got information in my Skinny on Skins file on how to do this.

Hopefully this helps a bit... Rick