site_archiver@lists.apple.com Delivered-To: pro-apps-dev@lists.apple.com http://lacquer.fi/FCPCocoaDragProblemDemoPlugin_binary_20090312.zip http://lacquer.fi/FCPCocoaDragProblemDemoPlugin_source_20090312.zip -- Pauli Ojala Lacquer oy/ltd pauli@lacquer.fi _______________________________________________ Do not post admin requests to the list. They will be ignored. Pro-apps-dev mailing list (Pro-apps-dev@lists.apple.com) Help/Unsubscribe/Update your Subscription: http://lists.apple.com/mailman/options/pro-apps-dev/site_archiver%40lists.ap... Ever since about FCP 6.0.2, I've been having strange and difficult-to- reproduce problems with FCP failing to render in response to events from my FxPlug plugin's Cocoa user interface. (I posted about it last year, and Paul Schneider was kind enough to make the "FloatingWindow" sample plugin as a barebones test case of a custom Cocoa window owned by an FxPlug, which was very helpful.) Now it looks like I've finally found the culprit: it's Cocoa drag & drop. More specifically, it appears that initiating a drag operation from an NSView in a Cocoa window is enough to put FCP in a state where its Canvas window is prevented from updating. There's a way to bring it back to life: one has to open the Video tab in the Viewer and click within the viewer's image (which is also unable to update and will thus contain pieces of the previous tab's view contents). I've modified the FloatingWindow sample as a test case for this problem. Here's the FxPlug and its source project: FWIW, the problem doesn't seem to occur on FCP 5.1.4, or any version of Motion. I'll file a bug report as well. For now I'm still stuck, as my plugin relies heavily on drag&drop (the user needs to be able to drag nodes into the effect composition view)... Can anyone think of a workaround? Would it perhaps be possible to use Carbon drag&drop between Cocoa views? This email sent to site_archiver@lists.apple.com