Help, *.CHM, etc

[Michael Geary]

> > > Technically os.system("c:\\path\\help.chm") and
> > > os.system("start c:\\path\\help.chm") also work,
> > > though are less intuitive.

> > No, os.system is the wrong way to do it. That function
> > launches a new command shell, which in turn runs
> > the program you want. Because of that, if you're not
> > already running in a console window, it will open a
> > new console window.
> >
> > You had it right with os.startfile. That calls the
> > ShellExecute function in Windows, which is the way
> > you would do it in a native Windows application
> > written in C.

> When the command completes, the window dissappears.
> This is the case when running from a script within
> pythonw or even inside of a py2exe frozen module.  While
> it may not be the 100% correct way of doing things (and
> you have to properly escape spaces in the file name, which
> then results in having to give a window title, etc.), it does
> result in a final outcome that is the same - the help file is
> open, your program continues execution.
>
> Certainly he will be using os.startfile(), but knowing that
> you can use windows shell commands with os.system
> can be useful.

Hi Josiah,

Yes, it is definitely useful to know that you can use os.system to run
Windows shell commands. That's what os.system is meant for. But you really
wouldn't want to use it to run a GUI app such as the HTML Help viewer.

If your application's Help menu opens a spurious console window along with
the help viewer, your users will wonder what the heck is going on. :-) It
also takes more memory and other resources, but that's less significant than
the user experience.

So do it the right way, with os.startfile. Or if you want more control over
the exact parameters to the underlying ShellExecute function, you can use
win32api.ShellExecute (if you know that the win32api module will be
available on the target systems).

-Mike