Please welcome guest blogger Dana Worley. Dana, a fellow Microsoft Help MVP, is the Software Product Manager at Campbell Scientific. She will present Migrating from WinHelp to HTML Help with Doc-to-Help at the WritersUA Conference in Long Beach.

In today's blog, Dana talks about some of the her experiences when using WinHelp on Vista.

*

In late December, the Microsoft Help MVPs were given the WinHlp32.exe beta by Microsoft. This executable will ultimately be the file that Vista users download to run 32-bit HLP files on Microsoft’s newest OS.

While my testing was by no means exhaustive, all-in-all I found very few problems. Some of the results of my tests follow. The software applications I tested were coded in Visual Basic and Delphi.

• The Table of Contents, Index, and Search all work normally.
• No problems with calls from the applications to the help, including context sensitive popups.
• Jumps to topics in secondary windows display as expected.
• No problems founds with mid-topic jumps.
• Macros such as Next(), Print(), and Close() work as expected.
• ExecFile macros (which I use for mailto and www links) do not execute. There is no message indicating a failure. Failure of these macros is not unexpected, since MS has really tried to step up its security efforts with the Vista operating system.
• With jumps from one HLP file to another, the behavior depends upon the location of the two help files. If they reside in the same directory, the jumps are successful. However, if the two help files reside in different directories, the user is prompted to search for the second file. The location of a “searched for” file is not written to the registry and, therefore, not stored for future help sessions.

Note that the 16-bit virtual environment (NTVDM) that shipped with Windows NT, Windows 2000, and Windows XP is still available in Windows Vista. Thus, for 16-bit help files, which use WinHelp.exe, there should be no difference in performance (and, no need to download a new help engine). But, we all dumped these a long time ago, right? :-)

While all of this looks promising, I still encourage you to make the transition to CHM or some other form of help as your company releases updates to its applications. Many help development tools provide quick and almost painless ways to import your legacy WinHelp projects.

As many of you may know, I attend a lot of conferences, but typically as a speaker. Last week, I was a conference attendee, and was a bit disappointed by the experience. (And I wasn't the only one, as I found out during lunch on the second day.) I'm obviously spoiled from attending the WritersUA Conference for the last 11 years ;-).

1. Fix the typos. I received a booklet that described all sessions and exhibitors. Typos were rampant (the one I loved was an exhibitor's description where their name was mistyped). And every PowerPoint presentation had at least one typo or grammar issue. Granted, this wasn't a "technical communication" conference...but really, typos matter.
2. Presentation descriptions should match the actual presentation. I attended six sessions over the two days, and only one matched the description. In one instance, I attended a Part II of a session, because I was already familiar with what was supposed to be discussed in Part I. Unfortunately, Part II ended up being a recap of Part I, but without the demos (which was what I was really interested in). (When I said something to one of the presenters, I was told that it did't matter. Uh, yeah, it does.)
3. Don't change the slides! None of the slides that were displayed on the overhead matched what I was given for reference. Extra slides were added. Information was added to or removed from slides. As a speaker, I know it's tough to create the decks in advance. I also know that late-breaking news may require changes (this is something that I run into a lot, mostly because of the subjects I talk about). But the changes I saw were not made because of late-breaking news...they were made because the presenter re-read the slides and wanted to modify the information.
4. Sales presentations have no place in conference sessions. Well, maybe that's too strong. If I know I'm attending a sales presentation, that's one thing. But two of the six sessions that I attended were sales presentations on why I should use Microsoft SharePoint (in one case, the previous version). If the session description had reflected what the session was actually about, I would have gone to a different session.

There was one bright spot. The conference was "paperless", which was really cool. All attendees received a 1Gb USB drive (branded, of course, but that's fine) in their badge holder that contained copies of almost all of the presentations. If you brought a laptop, you could follow along, and if you didn't, they provided printers where you could print out just the sessions you were going to attend. (OK, so I guess it wasn't totally paperless ;-).)

When I checked in, I received three handouts: a slim booklet that contained all of the descriptions, a coil-bound notebook that also contained the schedule for the two days, and a small exhibitor's map (that also included the schedule) which fit easily in a back pocket.

And to go along with the "paperless" conference, they used an online survey for evaluations. The email with the link was waiting when I logged on the night that the conference ended.

Unfortunately, I don't have any tips for attendees who end up at a similar conference. Maybe if I go again next year...