On 05/05/2011, at 10:01 AM, Jim Thomason wrote: > This gloriously ugly hack isn't the correct "why" question - the > correct "why" question is "why do I even need to do it?"
No, it is the right "why" question. When something is this hard, then you must clearly be fighting the designed architecture of the OS. And the reason you're fighting it is because you have arrived at a use-case it wasn't designed to handle, and the reason it wasn't designed to handle it is because the use-case is wrongly conceived. That's why you're being urged to go back to basics and reconsider that, rather than provided with a how-to for the case you HAVE proposed. > I want to be able to copy the current selection from another app so I > can use it in mine w/o requiring the user to do the copy first > themselves So.... why? If a service can't work (this is the designed-in solution in the architecture for what appears to be the use-case you've outlined) then certainly the solution you're looking at is wrong-headed at best. > set frontmost to true > keystroke "c" using command down > Yes, yes, I know that blissfully assuming that > command-C performs a copy operation is less than ideal. Best option > I've seen so far. This makes so many assumptions, it's not funny. Assuming that command-c does indeed pertain to the 'Copy' menu item, what does this even achieve? It merely sends a 'copy:' action to First Responder (even then that assumes that the 'Copy' menu item hasn't been wired to a different target and action, which would be perfectly legitimate). The chain of response to command-c is assumed to be - with question marks where it quite reasonably might not - : cmd-c -> ? -> Copy menu item -> ? -> [First Responder copy:] -> ? -> ( Implemented? Text object? valid selection? usable data type? )-> ? -> [NSPasteboard putData:] First Responder could be any object whatsoever within your user-interface, and it changes over time. There is no general solution for forcing any particular object or type of object to be First Responder from outside the app, unless it supports explicit scripting to do so. FR could be an object that doesn't respond to -copy: (the menu item would be typically greyed out in this case). If it does respond to -copy:, the implementation of that method could be anything whatsoever. Again, typically, but by no means necessarily, it might ultimately respond by placing data on to the general NSPasteboard. But then again, it might not - an app is free to implement copy however it pleases (though admittedly NOT using NSPasteboard would usually be perverse, but an app's definition of what it means to 'Copy' is certainly its own). The problem is, you need an app to put data onto a pasteboard (which from another apps perspective is at least sensible - pasteboards are an inter-application communication device), but between invoking the menu command 'Copy' and putting data on the pasteboard is a potentially vast swamp of unknown code to cross with no known outcome. Put another way, you are using a View behaviour to trigger a distant Data Model response, with who-knows-what result? The only reliable way to get an app to put data on a pasteboard is to invoke a service for which the app has opted in (even then, you can't "push" a service at an app, it has to "pull" the service into operation). So for the general case of any app, that isn't reliable. If an app is willing to share its data to the outside world, the best way for it to do that is to be scriptable, and to define specific script events to permit that in conjunction with other specific script events to determine exactly which object is being targeted. If the app's designer didn't build that in, you're stuck. There is no general solution for extracting data from an arbitrary app. You simply cannot do what you are attempting, at least as far as the problem has been defined. So, the only fruitful way forward is to redefine the problem, or give up and work on something more productive. --Graham _______________________________________________ Cocoa-dev mailing list (Cocoa-dev@lists.apple.com) Please do not post admin requests or moderator comments to the list. Contact the moderators at cocoa-dev-admins(at)lists.apple.com Help/Unsubscribe/Update your Subscription: http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to arch...@mail-archive.com
