• Open Menu Close Menu
  • Apple
  • Shopping Bag
  • Apple
  • Mac
  • iPad
  • iPhone
  • Watch
  • TV
  • Music
  • Support
  • Search apple.com
  • Shopping Bag

Lists

Open Menu Close Menu
  • Terms and Conditions
  • Lists hosted on this site
  • Email the Postmaster
  • Tips for posting to public mailing lists
Re: Problem with stopModalWithCode on a different thread
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Problem with stopModalWithCode on a different thread


  • Subject: Re: Problem with stopModalWithCode on a different thread
  • From: Charles Srstka <email@hidden>
  • Date: Tue, 22 Jun 2010 15:10:42 -0500

On Jun 22, 2010, at 1:54 PM, Bill Appleton wrote:

> Hi all,
>
> Thanks for the tips.
>
> i have verified that this code actually IS running on the main thread, i was wrong about that in my original message. Here is the situation. WebKit launches WebKitPluginHost.app and that is the process that runs my NPAPI plugin. The plugin is called on the main thread, and NSApp is already initialized. However I can absolutely confirm this bug is happening, I logged a webkit bug on it, no telling what will happen with that.
>
> i was able to fix this problem in my dialogs (not system dialogs) by just saving the clicked button in a global and calling abortModal, then i just return the global & it works perfectly. So Charles, your tip about "write your own method that wraps stopModalWithCode" is probably the practical way to fix this. But I can't subclass NSApp (it is already initialized) & I'm having trouble figuring out how to write a method that can just intercept a class message in general. Is that possible?

Wait a minute - why are you using NSApp in an NPAPI plug-in? NPAPI plug-ins could be loaded into a non-Cocoa browser such as Firefox that will not have an NSApp set, so this seems inadvisable (and could possibly be part of what is causing the weird behavior you’re seeing).

Apple seems to suggest that this sort of thing should not be done in an NPAPI plugin:

http://developer.apple.com/mac/library/documentation/InternetWeb/Conceptual/WebKit_PluginProgTopic/Tasks/NetscapePlugins.html#//apple_ref/doc/uid/30001250-DontLinkElementID_1

> 	• Use platform APIs sparingly. Wherever possible, you should use new plug-in APIs to do what you need. If no such APIs exist, file bugs requesting them.
> The plug-in API provides additional APIs for scheduling timers, opening contextual pop-up menus, and so on.
> Note: Calls to browser scripting functions work normally. WebKit transparently handles the interprocess communication for you.
> 	• Avoid creating windows. The intent is for plug-ins to operate within the browser window. Although some plug-ins have historically done so, creating windows in your plug-in is not recommended. If you need to maintain separate windows, you should consider starting a separate application.

Charles_______________________________________________

Cocoa-dev mailing list (email@hidden)

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:

This email sent to email@hidden

  • Follow-Ups:
    • Re: Problem with stopModalWithCode on a different thread
      • From: Bill Appleton <email@hidden>
References: 
 >Problem with stopModalWithCode on a different thread (From: Bill Appleton <email@hidden>)
 >Re: Problem with stopModalWithCode on a different thread (From: Jens Alfke <email@hidden>)
 >Re: Problem with stopModalWithCode on a different thread (From: Charles Srstka <email@hidden>)
 >Re: Problem with stopModalWithCode on a different thread (From: Bill Appleton <email@hidden>)

  • Prev by Date: Re: Problem with stopModalWithCode on a different thread
  • Next by Date: Re: Flip and Enlarge CALayer at the same time
  • Previous by thread: Re: Problem with stopModalWithCode on a different thread
  • Next by thread: Re: Problem with stopModalWithCode on a different thread
  • Index(es):
    • Date
    • Thread