site_archiver@lists.apple.com Delivered-To: pro-apps-dev@lists.apple.com Hi Pauli, - Paul On Mar 12, 2009, at 12:38 PM, Pauli Ojala wrote: 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/pschneider%40apple.com _______________________________________________ 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... Thanks for the sample plugin! This is an interesting and unexpected problem. It looks like the trick to "reset" Final Cut is to initiate a drag from within FCP's UI. Clicking in the Viewer will actually start a drag (you can drag the clip into the timeline that way). If I start a drag in the Timeline or Browser, it looks like FCP's canvas starts updating again, as well. I'm not sure what's causing this, although an odd interaction between Cocoa drag and drop and FCP's Carbon event handling is a plausible explanation. I'll look into it a little more. If your dragging happens entirely in one window, it might be possible to do some "fake" dragging of your own, but it would be nice if you didn't have to resort to such extreme measures. 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 pschneider@apple.com This email sent to site_archiver@lists.apple.com