King Simon-NFHD78 wrote: > Hello all, > > I am developing an application that, amongst other things, exports files > and then launches them in their associated applications using > os.startfile. It also uses webbrowser.open, which I see uses > os.startfile. > > Everything works on my PC and on all the other PCs in the office that I > have tested on. However, when we released our first version, a few users > reported unhandled exceptions that seem to be coming from os.startfile. > Here are some examples:
[... snipped ...] Unless someone comes in with something more authoritative, here are a few avenues to try: 1) According to this: http://groups.google.co.uk/group/microsoft.public.platformsdk.shell/msg/943b9844d480b029 ShellExecute on a URL invokes a shell extension handler which will operate in apartment threading mode. (ie you're using COM whether you like it or not). Exactly how this affects your situation I'm sure I couldn't say, especially since you seem to have tried that route and you're not specifying a COM threading model. 2) Is there any kind of consistency? ie does one user always fail on .csv while another fails on .kml? I'm sure this is stuff you'll have gone over yourself; I'm just trying to eliminate unknowns. I tried the obvious lack of associations and that comes up with a different message. 3) os.startfile basically just calls ShellExecute with the appropriate params. As an alternative, you could use FindExecutable from the win32api module of the pywin32 extensions, coupled with subprocess.call. Something like this: <code> import win32api import subprocess FILENAME = "c:/temp/test.csv" _, exename = win32api.FindExecutable (FILENAME) subprocess.call ([exename, FILENAME]) </code> Workaround, undoubtedly, and it won't work for URLs, but at least it might take you somewhere if you can't get the other thing working. TJG _______________________________________________ python-win32 mailing list [email protected] http://mail.python.org/mailman/listinfo/python-win32
