"Grant Edwards" <[EMAIL PROTECTED]> schrieb im Newsbeitrag news:[EMAIL PROTECTED] | On 2005-08-02, vincent wehren <[EMAIL PROTECTED]> wrote: | > | > "Grant Edwards" <[EMAIL PROTECTED]> schrieb im Newsbeitrag | > news:[EMAIL PROTECTED] | >|I have several python apps (some wxPython, some plain text-mode | >| stuff) that I distribute internally for installation on Win32 | >| machines. They're bundled/installed using py2exe and inno | >| setup. | >| | >| I followed what I think is the normal procedure of installing | >| each app in its own directory under /Program | >| Files/<vendor>/<app>. | >| | >| The problem is that the apps only run if they're started with | >| the install directory as the current working directory. | >| Otherwise they can't find the .dll's they use from the install | >| directory. | > | > AFAIK, Windows normally *does* search the directory where the executable | > module for the current process lives in for dlls. What sort of dlls are | > given you trouble? | | One's a "driver" for a CAN bus USB widget. The other failure | that springs to mind is that gnuplot-py couldn't find something | (could have been an .exe) that was in the app directory.
Grant, If you are building paths in you code that are relative to your app, please see my reply to Greg's post. If not, you may as a workaround want to try to add the frozen application's directory to the system path environment variable. Windows will look for dlls there, too. To get the app's actual location, you will need something like the getAppPrefix() function as per my reply to Greg's reply. The getAppPrefix() function will also hold when the user adds your frozen app to his/her system path and call the app from any location from the command line - sys.argv[0] just won't do the trick in such a setting. HTH, -- Vincent Wehren | | -- | Grant Edwards grante Yow! HUGH BEAUMONT died | at in 1982!! | visi.com -- http://mail.python.org/mailman/listinfo/python-list
