It's not my app, so it's all opaque to me. I'm trying to implement a service that sits up in the service menu.
So the user could, for my contrived example, be in Pages, type in their word, invoke my service, and get the definition automatically pasted into Pages for them. I don't have access to anything in whatever the invoking app is, so I can't just have an object over there refresh. I wouldn't have an object to invoke. I can fall back onto godawful hacks like programmatically sending a cmd-P event and hoping it pastes in my data, or using applescript to select the "paste" option from the edit menu, but that's the sort of nonsense I'm really trying to get away from. A standard service implementation already handles the I/O in the invoking app pretty well - it gets the right selection and pastes the results back into the right spot. But as best as I can tell, it requires that my service be single threaded and only transmits the results of the pasteboard when the sole service method completes. Honestly? The best horrible horrible hack I can come up with now is to layer it. So my service is just a very thin wrapper that does nothing but invoke my secondary real app to do the URL loading for me, and stick it onto the pasteboard. The service would invoke the wrapper, which would launch the real app and block until it gets its response from there, then unblock pop it onto the pasteboard when the secondary completes. I'm not sure if I could even get this working properly. Needing to use a thin wrapper to invoke the real app is pretty goofy, but I think it would work. And it lets me use the rest of the services implementation for my cutting and pasting without reverting to hacks like trying to invoke copy and paste events. But I dunno, if I need to fall back on something like that, I really felt like something went wrong. Opinions on that double-app strategy would also be welcome, in addition to any better ideas, which I desperately hope exist. On Fri, Jan 11, 2013 at 11:08 AM, Alex Zavatone <z...@mac.com> wrote: > Can you declare a callback that gets automatically called when the web > request completes, then as a result of this new entry point issues a "needs > refresh" to the GUI item you care about? That GUI item then grabs the data > from the source it's tied to which you have just updated as part of the > call back? > > Of course, this implies a proposed flow for a non error case. > > Do I understand this correctly? > > It seems like you want to make sure this happens off the main thread, so > that the GUI can still be responsive, so you could issue a GCD block or use > some of the great open source libs out that kind people have already put > together to handle async net communication. > > > On Jan 11, 2013, at 11:59 AM, Jim Thomason wrote: > > > Gang, > > > > In my fighting with services, I'm trying a different approach and hence > > have a different question - is there a way that I could craft a service > > that reads in selected text, uses that to open and perform a web > > connection, and then returns that data back to the calling app? > > > > The trivially silly example I have would be a service that looks up the > > definition of a word and pastes the definition in place. So I might > select > > the word "apple" and invoke my service, and it goes off and searches the > > web or my central server or something and pastes back into place "An > > awesome computer company and/or fruit". No, I don't know why anyone would > > want such a service, this is just to illustrate the concept. > > > > The issue is that my -doWebStuff:userData:error: method seems to only let > > me write to the pasteboard during the invocation of that method, and once > > it completes I'm done. NSURLConnection is all delegate based, so I > wouldn't > > have the results of my lookup until the secondary thread completes and my > > delegate realizes its done loading the data. By that point, the > doWebStuff > > method is long since completed and I'm stuck w/o results. > > > > I can see a few different hypothetical ways to make this work: > > (a) somehow block the main thread until the secondary threads come back. > > I'm not sure this'd work since the delegate method would be invoked on > the > > main thread, which I'm currently blocking. > > > > (b) Somehow update the pasteboard after the service method finished? > > > > (c) Somehow defer my way out of the method to do something else, then hop > > back in when I'm done? Something like the concept of a promise in > > javascript. I'm grasping at straws here. > > > > (d) Might NSOperationQueue be magical enough to allow something like > this? > > > > > > I'm stumped. For now, I think this just gets filed under "Can't be done" > > since by everything I can tell I have to do all work in a service in that > > single invocation of the single method in the single thread, and anything > > that'd cause me to hop out of there kills the concept. > > > > Does anybody have a method to do this? Or is it just not possible? > > > > Many thanks, > > > > -Jim..... > > _______________________________________________ > > > > 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: > > https://lists.apple.com/mailman/options/cocoa-dev/zav%40mac.com > > > > This email sent to z...@mac.com > > _______________________________________________ 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: https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to arch...@mail-archive.com
