For the life of me, I can’t seem to get MacOpenFile to work…the other OSX specific callbacks in wx.App seem to work just fine (MacReopenApp, MacNewFile). What I’m wanting is for my application to run and then open a particular file when that file is double clicked in the Finder. What’s happening right now is that the app runs, but MacOpenFile is never called.
I also instrumented wxApp::MacOpenFile() and wxApp::MacHandleAEODoc() down in wxWidgets src/osx/carbon/app.cpp, but none of that is called either. I scoured the Internet for info, but it seems like everyone who ended up using MacOpenFile correctly, it worked just fine for them.
The app freezing is done with pyinstaller, in one-dir mode; so I don’t think is any funny business forking another process; I monitored the process ID throughout the life of the application, and it seemed to stay constant.
So I’m not sure what to ask even…perhaps for suggestions in tracking down the problem? I’m not that familiar with whatever magic OSX is using to pass the file information to the application. Another wondering…would I be able to test the python script directly without freezing for this sort of thing (some sort of Info.plist magic incantation).
Why not try: debugger_name your_script.py where debugger name could
be winpdb/ddd/some other python debugger - that will leave freeze
out of the equation completely.
···
On 24/02/13 21:37, dhyams wrote:
wxPython 2.9.1.1 OSX/carbon
For the life of me, I can't seem to get MacOpenFile to
work…the other OSX specific callbacks in wx.App seem to work
just fine (MacReopenApp, MacNewFile). What I’m wanting is for my
application to run and then open a particular file when that
file is double clicked in the Finder. What’s happening right
now is that the app runs, but MacOpenFile is never called.
I also instrumented wxApp::MacOpenFile() and
wxApp::MacHandleAEODoc() down in wxWidgets
src/osx/carbon/app.cpp, but none of that is called either. I
scoured the Internet for info, but it seems like everyone who
ended up using MacOpenFile correctly, it worked just fine for
them.
The app freezing is done with pyinstaller, in one-dir mode;
so I don’t think is any funny business forking another process;
I monitored the process ID throughout the life of the
application, and it seemed to stay constant.
So I'm not sure what to ask even...perhaps for suggestions in
tracking down the problem? I’m not that familiar with whatever
magic OSX is using to pass the file information to the
application. Another wondering…would I be able to test the
python script directly without freezing for this sort of thing
(some sort of Info.plist magic incantation).
Sorry for the rambling…
–
You received this message because you are subscribed to the Google
Groups “wxPython-users” group.
To unsubscribe from this group and stop receiving emails from it,
For the life of me, I can't seem to get MacOpenFile to
work…the other OSX specific callbacks in wx.App seem to work
just fine (MacReopenApp, MacNewFile). What I’m wanting is for my
application to run and then open a particular file when that
file is double clicked in the Finder. What’s happening right
now is that the app runs, but MacOpenFile is never called.
I also instrumented wxApp::MacOpenFile() and
wxApp::MacHandleAEODoc() down in wxWidgets
src/osx/carbon/app.cpp, but none of that is called either. I
scoured the Internet for info, but it seems like everyone who
ended up using MacOpenFile correctly, it worked just fine for
them.
The app freezing is done with pyinstaller, in one-dir mode;
so I don’t think is any funny business forking another process;
I monitored the process ID throughout the life of the
application, and it seemed to stay constant.
So I'm not sure what to ask even...perhaps for suggestions in
tracking down the problem? I’m not that familiar with whatever
magic OSX is using to pass the file information to the
application. Another wondering…would I be able to test the
python script directly without freezing for this sort of thing
(some sort of Info.plist magic incantation).
Sorry for the rambling…
–
You received this message because you are subscribed to the Google
Groups “wxPython-users” group.
To unsubscribe from this group and stop receiving emails from it,
I must be missing something with the MacOpenFile…I copied the sample app from here: Optimizing for Mac OS X - wxPyWiki, and it’s attached here for convenience. According to that wiki page, you should be able to drag and drop a file from the Finder to the app, as long as you have the Option key pressed, and it will show a little dialog in response. It doesn’t work for me, and I’ve tried running it directly as a script, and also packaged with py2app (used the py2app packaging script also on that same wiki page).
Also tried wxPython 2.8.11-carbon, wxPython-2.9.1.1-carbon, and wxPython 2.9.4.0-cocoa. No response from any.
So I just wanted to ask a favor; can someone with a mac download the attached script, run it, and Option-drag a file from the Finder to the script’s window, to see if it responds? Surely I’m missing something
For the life of me, I can't seem to get MacOpenFile to
work…the other OSX specific callbacks in wx.App seem to work
just fine (MacReopenApp, MacNewFile). What I’m wanting is for my
application to run and then open a particular file when that
file is double clicked in the Finder. What’s happening right
now is that the app runs, but MacOpenFile is never called.
I also instrumented wxApp::MacOpenFile() and
wxApp::MacHandleAEODoc() down in wxWidgets
src/osx/carbon/app.cpp, but none of that is called either. I
scoured the Internet for info, but it seems like everyone who
ended up using MacOpenFile correctly, it worked just fine for
them.
The app freezing is done with pyinstaller, in one-dir mode;
so I don’t think is any funny business forking another process;
I monitored the process ID throughout the life of the
application, and it seemed to stay constant.
So I'm not sure what to ask even...perhaps for suggestions in
tracking down the problem? I’m not that familiar with whatever
magic OSX is using to pass the file information to the
application. Another wondering…would I be able to test the
python script directly without freezing for this sort of thing
(some sort of Info.plist magic incantation).
Sorry for the rambling…
–
You received this message because you are subscribed to the Google
Groups “wxPython-users” group.
To unsubscribe from this group and stop receiving emails from it,
I must be missing something with the MacOpenFile...I copied the sample
app from here: Optimizing for Mac OS X - wxPyWiki,
and it's attached here for convenience. According to that wiki page, you
should be able to drag and drop a file from the Finder to the app, *as
long as you have the Option key pressed*, and it will show a little
dialog in response. It doesn't work for me, and I've tried running it
directly as a script, and also packaged with py2app (used the py2app
packaging script also on that same wiki page).
Also tried wxPython 2.8.11-carbon, wxPython-2.9.1.1-carbon, and wxPython
2.9.4.0-cocoa. No response from any.
So I just wanted to ask a favor; can someone with a mac download the
attached script, run it, and Option-drag a file from the Finder to the
script's window, to see if it responds? Surely I'm missing something
MacOpenFiles is called in response to files being dropped on the application's doc or finder icon, or for things like double clicking on files that the app has registered itself as a handler for. It is *not* called for DnD of files dropped in the application window. To do that you need to set up an appropriate drop target and assign it to a window.
Very true; I got into a “can’t see the forest because of the trees” mode. I thought that there might be some OSX magic going on such that when a drag/drop occurred, MacOpenFile got called.
I’ll keep plugging away on it, using the right paradigm. Am I correct, though, in thinking that when a user double-clicks a file associated with my application, my application should start up and, at some point, MacOpenFile should be called? That’s the part that I can’t get to work. Right now, the application starts up, but MacOpenFile is never called.
I’ll continue to work with the sample mac app. Thanks Robin.
and it’s attached here for convenience. According to that wiki page, you
should be able to drag and drop a file from the Finder to the app, *as
long as you have the Option key pressed*, and it will show a little
dialog in response. It doesn’t work for me, and I’ve tried running it
directly as a script, and also packaged with py2app (used the py2app
packaging script also on that same wiki page).
Also tried wxPython 2.8.11-carbon, wxPython-2.9.1.1-carbon, and wxPython
2.9.4.0-cocoa. No response from any.
So I just wanted to ask a favor; can someone with a mac download the
attached script, run it, and Option-drag a file from the Finder to the
script’s window, to see if it responds? Surely I’m missing something
MacOpenFiles is called in response to files being dropped on the application’s doc or finder icon, or for things like double clicking on files that the app has registered itself as a handler for. It is not called for DnD of files dropped in the application window. To do that you need to set up an appropriate drop target and assign it to a window.
I believe MacOpenFile only works after the application is started on Mac. If your app starts in response to a double-click on an associated file, I think the filename is passed in with the sys.argv arguments, so you should pull it from there.
Regards,
Kevin
···
On Apr 2, 2013, at 5:39 AM, Daniel Hyams wrote:
Very true; I got into a “can’t see the forest because of the trees” mode. I thought that there might be some OSX magic going on such that when a drag/drop occurred, MacOpenFile got called.
I’ll keep plugging away on it, using the right paradigm. Am I correct, though, in thinking that when a user double-clicks a file associated with my application, my application should start up and, at some point, MacOpenFile should be called? That’s the part that I can’t get to work. Right now, the application starts up, but MacOpenFile is never called.
I’ll continue to work with the sample mac app. Thanks Robin.
and it’s attached here for convenience. According to that wiki page, you
should be able to drag and drop a file from the Finder to the app, *as
long as you have the Option key pressed*, and it will show a little
dialog in response. It doesn’t work for me, and I’ve tried running it
directly as a script, and also packaged with py2app (used the py2app
packaging script also on that same wiki page).
Also tried wxPython 2.8.11-carbon, wxPython-2.9.1.1-carbon, and wxPython
2.9.4.0-cocoa. No response from any.
So I just wanted to ask a favor; can someone with a mac download the
attached script, run it, and Option-drag a file from the Finder to the
script’s window, to see if it responds? Surely I’m missing something
MacOpenFiles is called in response to files being dropped on the application’s doc or finder icon, or for things like double clicking on files that the app has registered itself as a handler for. It is not called for DnD of files dropped in the application window. To do that you need to set up an appropriate drop target and assign it to a window.
I believe MacOpenFile only works after the application is started on Mac. If your app starts in response to a double-click on an associated file, I think the filename is passed in with the sys.argv arguments, so you should pull it from there.
Regards,
Kevin
On Apr 2, 2013, at 5:39 AM, Daniel Hyams wrote:
Very true; I got into a “can’t see the forest because of the trees” mode. I thought that there might be some OSX magic going on such that when a drag/drop occurred, MacOpenFile got called.
I’ll keep plugging away on it, using the right paradigm. Am I correct, though, in thinking that when a user double-clicks a file associated with my application, my application should start up and, at some point, MacOpenFile should be called? That’s the part that I can’t get to work. Right now, the application starts up, but MacOpenFile is never called.
I’ll continue to work with the sample mac app. Thanks Robin.
and it’s attached here for convenience. According to that wiki page, you
should be able to drag and drop a file from the Finder to the app, *as
long as you have the Option key pressed*, and it will show a little
dialog in response. It doesn’t work for me, and I’ve tried running it
directly as a script, and also packaged with py2app (used the py2app
packaging script also on that same wiki page).
Also tried wxPython 2.8.11-carbon, wxPython-2.9.1.1-carbon, and wxPython
2.9.4.0-cocoa. No response from any.
So I just wanted to ask a favor; can someone with a mac download the
attached script, run it, and Option-drag a file from the Finder to the
script’s window, to see if it responds? Surely I’m missing something
MacOpenFiles is called in response to files being dropped on the application’s doc or finder icon, or for things like double clicking on files that the app has registered itself as a handler for. It is not called for DnD of files dropped in the application window. To do that you need to set up an appropriate drop target and assign it to a window.
are you using py2app with argv_emulation on? that's what does the magic.
-Chris
···
On Tue, Apr 2, 2013 at 8:32 AM, Daniel Hyams <dhyams@gmail.com> wrote:
I wish the filename was in argv! The fact that it's not is what has set me
on this path to wrestle with MacOpenFile.
--
Christopher Barker, Ph.D.
Oceanographer
Emergency Response Division
NOAA/NOS/OR&R (206) 526-6959 voice
7600 Sand Point Way NE (206) 526-6329 fax
Seattle, WA 98115 (206) 526-6317 main reception
I believe MacOpenFile only works after the application is started on
Mac. If your app starts in response to a double-click on an associated
file, I think the filename is passed in with the sys.argv arguments, so
you should pull it from there.
I think that is only if py2app's argv_emulation option is turned on. Does pyinstaller have something similar? Otherwise I think it comes through one of the apple events, however I don't think I've actually tried it myself in a real application so I'm not sure.
Very true; I got into a "can't see the forest because of the trees"
mode. I thought that there might be some OSX magic going on such that
when a drag/drop occurred, MacOpenFile got called.
I'll keep plugging away on it, using the right paradigm. Am I correct,
though, in thinking that when a user double-clicks a file associated
with my application, my application should start up and, at some
point, MacOpenFile should be called? That's the part that I can't get
to work. Right now, the application starts up, but MacOpenFile is
never called.
I noticed that you are using wxPython 2.9.1.1 OSX/carbon. Does it make any difference if you use 2.9.4 and the Cocoa build?
OK, here are a couple of things that I found out tonight, and posting them here in hopes that they are useful to someone else. Tested with 2.9.1.1-carbon.
The “app” referred to here is the one downloadable here: http://wiki.wxpython.org/Optimizing%20for%20Mac%20OS%20X. Appropriate changes have been made to the Info.plist (after building) in order to associate an extension “foo” with this app.
if the app is packaged with py2app, argv_emulation on, py2app successfully places the name of the file in sys.argv as advertised. This works in both cases a) associated data file dragged onto the app icon, and b) double clicking the associated data file to run the app. MacOpenFile is not called, because py2app intercepted the related AppleEvent.
if the app is packaged with py2app, argv_emulation off, now MacOpenFile is called, and the name of the file passed to it is correct. This says that wxwidgets/wxPython is working just fine. MacOpenFile is called correctly in both cases a) associated data file dragged onto the app icon, and b) double clicking the associated data file to run the app.
if the app is packaged with pyinstaller, MacOpenFile is not called. I can only guess that the AppleEvent is being eaten somewhere along the way, or there is a fork somewhere along the way in pyinstaller that might “pull the rug” from underneath the process that the AppleEvents are sent to. Because (2) above works, I don’t think that the argv_emulation is necessary for pyinstaller to support.
So this is good news in a way; and looks like it is a pyinstaller-specific issue. If anyone has any thoughts at all on how to pursue what’s different about pyinstaller and py2app that causes this issue, I’m all ears The only thing I can think of off of the top of my head is to replicate the installation of AppleEvents handlers (like wxwidgets does) and run a fake event loop (like py2app can if argv_emulation is activated) in the pyinstaller bootloader, in the hopes that the events will be there to grab, and then dump the filename(s) into sys.argv.
I believe MacOpenFile only works after the application is started on
Mac. If your app starts in response to a double-click on an associated
file, I think the filename is passed in with the sys.argv arguments, so
you should pull it from there.
I think that is only if py2app’s argv_emulation option is turned on. Does pyinstaller have something similar? Otherwise I think it comes through one of the apple events, however I don’t think I’ve actually tried it myself in a real application so I’m not sure.
Very true; I got into a “can’t see the forest because of the trees”
mode. I thought that there might be some OSX magic going on such that
when a drag/drop occurred, MacOpenFile got called.
I’ll keep plugging away on it, using the right paradigm. Am I correct,
though, in thinking that when a user double-clicks a file associated
with my application, my application should start up and, at some
point, MacOpenFile should be called? That’s the part that I can’t get
to work. Right now, the application starts up, but MacOpenFile is
never called.
I noticed that you are using wxPython 2.9.1.1 OSX/carbon. Does it make any difference if you use 2.9.4 and the Cocoa build?
To follow up on this (as a pointer to those looking for the same answer in the future), I submitted a pull request to the pyinstaller devs to take care of this issue:
The summary there describes what had to be done; the basic issue is that pyinstaller starts up a child process for the python code to be executed in, but the AppleEvents are only send by OSX to the parent process (which is all one could expect, really). So if packaged with pyinstaller, there is no opportunity for wxWidgets/wxPython to see these startup AppleEvents.
So pyinstaller is modified such that it catches the events (like py2app) and sticks the filenames in argv for you.
···
On Sunday, February 24, 2013 4:37:49 PM UTC-5, dhyams wrote:
wxPython 2.9.1.1 OSX/carbon
For the life of me, I can’t seem to get MacOpenFile to work…the other OSX specific callbacks in wx.App seem to work just fine (MacReopenApp, MacNewFile). What I’m wanting is for my application to run and then open a particular file when that file is double clicked in the Finder. What’s happening right now is that the app runs, but MacOpenFile is never called.
I also instrumented wxApp::MacOpenFile() and wxApp::MacHandleAEODoc() down in wxWidgets src/osx/carbon/app.cpp, but none of that is called either. I scoured the Internet for info, but it seems like everyone who ended up using MacOpenFile correctly, it worked just fine for them.
The app freezing is done with pyinstaller, in one-dir mode; so I don’t think is any funny business forking another process; I monitored the process ID throughout the life of the application, and it seemed to stay constant.
So I’m not sure what to ask even…perhaps for suggestions in tracking down the problem? I’m not that familiar with whatever magic OSX is using to pass the file information to the application. Another wondering…would I be able to test the python script directly without freezing for this sort of thing (some sort of Info.plist magic incantation).
The only thing I can think of off of the top of my head is to replicate the installation of AppleEvents handlers (like wxwidgets does) and run a fake event loop (like py2app can if argv_emulation is activated) in the pyinstaller bootloader, in the hopes that the events will be there to grab, and then dump the filename(s) into sys.argv.