Tim Golden wrote: > 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: >
Hi Tim, Thanks a lot for responding. > 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. > I built the example code from that thread, and was able to get ShellExecute to fail by using COINIT_MULTITHREADED, but A) It only failed for URLs - launching a .txt file seemed to work either way. B) When it did fail, the error message was the same as the one I was getting in python - "The requested lookup key was not found in any active activation context." I don't think this is my problem. > > 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. > I need to investigate this further. Remote debugging via email, with users in different time zones, is a slow process :-) > 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 Thanks a lot for this - I may well end up using it. I have a slight worry that it won't work in the face of "funny" ways of opening documents (ie. DDE), but it'll be easy enough to find out. Thanks again for your help, Simon _______________________________________________ python-win32 mailing list python-win32@python.org http://mail.python.org/mailman/listinfo/python-win32
