site_archiver@lists.apple.com Delivered-To: macnetworkprog@lists.apple.com But then you wrote... ... and that doesn't really gel with my theory. It's easy to check this stuff with the <x-man-page://1/codesign> tool. Share and Enjoy -- Quinn "The Eskimo!" <http://www.apple.com/developer/> Apple Developer Relations, Developer Technical Support, Core OS/Hardware _______________________________________________ Do not post admin requests to the list. They will be ignored. Macnetworkprog mailing list (Macnetworkprog@lists.apple.com) Help/Unsubscribe/Update your Subscription: http://lists.apple.com/mailman/options/macnetworkprog/site_archiver%40lists.... At 15:25 -0400 17/3/09, David Gagnon wrote: And it does not work well all the time, especially when our plug-in is running into Acrobat 9 (it is working in Acrobat 8). Sometimes, we received kCFStreamEventEndEncountered in ReadStreamClientCallBack and sometimes we received nothing. My first thought on this topic is that, as a plug-in, you're at the mercy of the host application when it comes to runloop callbacks. If Acrobat is doing something wacky with the thread it calls you on, all sorts of bad things can happen. Also, we discovered that turning on and off the firewall can fix the problem but for 1 time only. Do you know if the fact that our product is a plug-in can be the cause of the problem? Well, yes, in all sorts of odd ways. In general I would recommend that create a dummy application that you can use to host your plug-in during development. If emulating the full plug-in API is too hard, just create a dummy bundle that contains your code and run it from there. This will allow you to debug your core networking code in a reasonable environment. Do you know if the application signature of Acrobat is changed when our plug-in is copied into Acrobat? I presume you're using "signature" in the code signing sense. If so, the answer depends on how Acrobat was signed. If Acrobat is signed by Adobe then they get to specify the rules about what breaks the bundle's seal and what doesn't. If Acrobat is being signed ad hoc (by, for example, the firewall), the standard resource rules apply, and in that case any modification of the bundle (exception the removal of lproj's, IIRC) will break the seal. This email sent to site_archiver@lists.apple.com