Help, *.CHM, etc

[Tom]

A question for gui application programmers. . .
I 've got some GUI programs, written in Python/wxPython, and I've got
a help button and a help menu item. Also, I've got a compiled file
made with the microsoft HTML workshop utility, lets call it
c:\path\help.chm. My question is how do you launch it from the GUI?
What logic do I put behind the "help" button, in other words.

I thought it would be

os.spawnv(os.P_DETACH, "c:\\path\\help.chm", [])

but I get an error:

OSError: [Errno 8] Exec format error

so I guess help.chm isn't executable itself, but is associated with
some unknown executable. I tried explorer.exe- at the dos cmd line it
basically works to type

explorer.exe c:\path\help.chm

although there is a nag screen that would be nice to do without.

so you'd think

os.spawnv(os.P_DETACH, 'explorer.exe', ["c:\\path\\help.chm"])

would be equivalent but it fails. I have to believe someone out there
in python community likes to include help.chm with their applications,
nad there is a right way to do this.

On another note, are there pure python based help viewers that people
use instead? The reason I ask is that would be more portable then the
*.chm files are. If there is such a beast I can't find it.

[Josiah Carlson]

> A question for gui application programmers. . .

I 've got some GUI programs, written in Python/wxPython, and I've got
a help button and a help menu item. Also, I've got a compiled file
made with the microsoft HTML workshop utility, lets call it
c:\path\help.chm. My question is how do you launch it from the GUI?
What logic do I put behind the "help" button, in other words.

I thought it would be

os.spawnv(os.P_DETACH, "c:\\path\\help.chm", [])
needs to be:

os.spawnv(os.P_DETACH, "c:\\path\\help.chm", ["c:\\path\\help.chm"])
so I guess help.chm isn't executable itself, but is associated with
some unknown executable. I tried explorer.exe- at the dos cmd line it
basically works to type os.spawnv(os.P_DETACH, 'explorer.exe', ["c:\\path\\help.chm"])
os.spawnv(os.P_DETACH, 'explorer.exe', ['explorer.exe', "c:\\path\\help.chm"])
would be equivalent but it fails. I have to believe someone out there
in python community likes to include help.chm with their applications,
nad there is a right way to do this.

On another note, are there pure python based help viewers that people
use instead? The reason I ask is that would be more portable then the
*.chm files are. If there is such a beast I can't find it.

Personally, I would suggest:
os.startfile("c:\\path\\help.chm")

It is documented to do exactly what you want it to do, open up the help
file with the microsoft help file viewer.

- Josiah

[Josiah Carlson]

> Personally, I would suggest:

os.startfile("c:\\path\\help.chm")

It is documented to do exactly what you want it to do, open up the help
file with the microsoft help file viewer.

That is, if .chm files are associated with the microsoft help file
viewer.

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

- Josiah

[Michael Geary]

Josiah Carlson wrote:

Personally, I would suggest:
os.startfile("c:\\path\\help.chm")

It is documented to do exactly what you want it to do,
open up the help file with the microsoft help file viewer.

That is, if .chm files are associated with the microsoft
help file viewer.

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.

-Mike

[Josiah Carlson]

> > 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.

Mike,

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.

- Josiah

[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

[Markus Wankus]

If you are interested, here is a snippet of how I did it a long time ago
in a galaxy far, far away. It avoids spawning multiple instances of the
same .chm.

#
----------------------------------------------------------------------------
# The Help..Contents menu command
def OnMnuHelpContents(self, event):
"""This method opens the Help file (if it isn't open already)."""
# Display the help file - nothing fancy - just run it
# ToDo - if already running bring to top (I can't see a way to do
# this, currently)
global helpfile_active

helpfilename = os.path.join(r'path_to_your_helpfile',
r'yourhelpfile.chm')
if not helpfile_active:
helpprocid = wxNewId()
self.helpfile_process = wxProcess(self, helpprocid)
EVT_END_PROCESS(self, helpprocid, self.OnHelpWindowTerminate)
helpfile_active = wxExecute('hh.exe %s' % helpfilename, False,
self.helpfile_process)
#
----------------------------------------------------------------------------
def OnHelpWindowTerminate(self, event):
"""This event function is fired when the help window is closed."""
global helpfile_active

if helpfile_active:
self.helpfile_process.Detach()
self.helpfile_process.Destroy()
helpfile_active = 0
#
----------------------------------------------------------------------------

Couldn't tell you if os.startfile is better or not...but I imagine
wxExecute is calling the Windows ShellExecute under the covers anyway. Of
course, this also fails if they do not have hh.exe installed but this is
only on stock Win95 or older NT machines with IE < 5.0. I imagine you
could spruce it up with more error checking.

You may also want to get rid of the global and use a real attribute...this
is from my beginner days. ;o)

Markus.

On 20 Jan 2004 18:03:36 -0800, Tom <it********@yahoo.com> wrote:

A question for gui application programmers. . .
I 've got some GUI programs, written in Python/wxPython, and I've got
a help button and a help menu item. Also, I've got a compiled file
made with the microsoft HTML workshop utility, lets call it
c:\path\help.chm. My question is how do you launch it from the GUI?
What logic do I put behind the "help" button, in other words.

I thought it would be

os.spawnv(os.P_DETACH, "c:\\path\\help.chm", [])

but I get an error:

OSError: [Errno 8] Exec format error

so I guess help.chm isn't executable itself, but is associated with
some unknown executable. I tried explorer.exe- at the dos cmd line it
basically works to type

explorer.exe c:\path\help.chm

although there is a nag screen that would be nice to do without.

so you'd think

os.spawnv(os.P_DETACH, 'explorer.exe', ["c:\\path\\help.chm"])

would be equivalent but it fails. I have to believe someone out there
in python community likes to include help.chm with their applications,
nad there is a right way to do this.

On another note, are there pure python based help viewers that people
use instead? The reason I ask is that would be more portable then the
*.chm files are. If there is such a beast I can't find it.

[Tom]

Hah, thanks for the prompt help. I've been using the _programming on
win32_ (Hammond) book as a reference and now I see that right under
spawnve in Appendix A p. 523 (which I was using as my os module
reference) is the bit about system(command). From C that should have
been obvious.

Trying it, os.system() didn't really work but os.startfile() works
exactly as I'd like it. fixing my os.system() call is probably is
easy but irrellevant.

As for the other question, a portable html browser that looks & feels
like the chm help browser. I realized that Boa Constructor Project
has such a component, since I've used Boa help in windows and unix. I
wonder if anyone has written a cross-platform CHM decoder and browser
that has the help browser look & feel. I can't find one, but it seems
that python would be a great language to make such a thing. Maybe
I'll take a crack if it hasn't been done. I like monolithic,
compressed help vs. a big directory full of html.

[Jarek Zgoda]

Michael Geary <Mi**@DeleteThis.Geary.com> pisze:

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.

Only if you don't pretend to be "Real-Hardcore-Win32-Hackah". We use
CreateProcessEx.

--
Jarek Zgoda
Unregistered Linux User #-1
http://www.zgoda.biz/ JID:zgoda-a-chrome.pl http://zgoda.jogger.pl/

[JanC]

it********@yahoo.com (Tom) schreef:

As for the other question, a portable html browser that looks & feels
like the chm help browser. I realized that Boa Constructor Project
has such a component, since I've used Boa help in windows and unix. I
wonder if anyone has written a cross-platform CHM decoder and browser
that has the help browser look & feel. I can't find one, but it seems
that python would be a great language to make such a thing. Maybe
I'll take a crack if it hasn't been done. I like monolithic,
compressed help vs. a big directory full of html.

helpviewer.py in site-packages/wxPython/tools is part of wxPython, not Boa:

"""
helpviewer.py -- Displays HTML Help in a wxHtmlHelpController window.

Usage:
helpviewer [--cache=path] helpfile [helpfile(s)...]

Where helpfile is the path to either a .hhp file or a .zip file
which contians a .hhp file. The .hhp files are the same as those
used by Microsoft's HTML Help Workshop for creating CHM files.
"""
Also try xCHM for a cross-platform .CHM viewer:
<http://xchm.sourceforge.net/>

--
JanC

"Be strict when sending and tolerant when receiving."
RFC 1958 - Architectural Principles of the Internet - section 3.9