site_archiver@lists.apple.com Delivered-To: pro-apps-dev@lists.apple.com User-agent: Thunderbird 2.0.0.14 (Windows/20080421) Hei, A simple piece of example code to reproduce: - (NSView *)createViewForParm:(UInt32)parmId { NSView * view = NULL; [editButton release]; [cfgButton release]; } return view; } Hi, all, - Paul On Mar 10, 2008, at 12:07 PM, Darrin Cardani wrote: On Mar 10, 2008, at 7:56 AM, Steve Christensen wrote: On Mar 10, 2008, at 2:42 AM, Stig Sandø wrote: Darrin -- Darrin Cardani dcardani@apple.com <mailto:dcardani@apple.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/ses%40vizrt.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... I finally was able to have a look at this issue again after being away for awhile. What I realised was that I had been changing the frame size in -createViewForParm, but was testing on the same plugin instance, ie I used a symbolic link to to the build-dir and tested. So despite recompiling with a different initial size, (initWithFrame) the parameter view remained the same size, but the content within was changing. So eventually I tried a new plugin instance, with code that requested quite a liberal height. And now it got the request height. What had been wrong? So I changed the code to use a more conservative height, recompiled, restarted FCP but the instance kept it's earlier liberal size. So to me it seems like FCP keeps/saves the initial size of the view the first time it is created and is using that later, despite the plugin handing over a view with a different size. This seems odd to me. Maybe someone can elaborate? In our use-case we had hoped to have a dynamic size of this parameter window, both depending on what input options are relevant, as well as giving newer versions of the plugin the opportunity to adapt the view and view-size. In our case we only need one stored parameter that keeps the entire state. if (parmId == (SessionParamID)) { // changing the height here should also update the size of existing/deserialised plugins view = [[NSView alloc] initWithFrame: NSMakeRect(0, 0, 60, 90)]; NSButton *editButton = [[NSButton alloc] initWithFrame: NSMakeRect(0, 0, 140, 25)]; [editButton setTitle:@"Editor"]; [[editButton cell] setFont: [NSFont systemFontOfSize: [NSFont smallSystemFontSize]]]; [editButton setBezelStyle:NSRoundedBezelStyle]; [editButton setTarget: self]; [editButton setAction: @selector(launchEditor)]; [view addSubview:editButton positioned:NSWindowAbove relativeTo: nil]; NSButton *cfgButton = [[NSButton alloc] initWithFrame: NSMakeRect(0, 30, 140, 25)]; [cfgButton setTitle:@"Config"]; [[cfgButton cell] setFont: [NSFont systemFontOfSize: [NSFont smallSystemFontSize]]]; [cfgButton setBezelStyle:NSRoundedBezelStyle]; [cfgButton setTarget: self]; [cfgButton setAction: @selector(launchConfigure)]; [view addSubview:cfgButton positioned: NSWindowAbove relativeTo: editButton]; Paul Schneider skrev: Darrin is right, you *should* be able to tell the host that your view is as large as you want. However, FCP isn't quite that friendly. We will use the initial height you specify, but we will resize the view down to the width of the parameters column. The user can make the parameters column wider or narrower by dragging the column header, and we should dynamically resize your view as the column changes size. You can't specify it programatically, but you can tell your users to resize the column to make your UI more usable - many developers are in this situation currently. We should use the initial height you specify, though. In testing some other plugins (like the SimpleMatte SDK example), it looks like this is working, so the problem may be with your nib or view. we're seeing that in FCP 6 our custom UI parameters seem to be restricted to a certain width, and more worryingly to a height of about 30 pixels. Is there a way to work around this to provide bigger/taller custom UIs? Unless I've been lucky, it sounds like the problem is with your NSView. I have a custom view that contains a 160 x 67 pixel image. The full height of the image is visible in the Viewer window, although the right edge can be clipped if the Parameters column width is reduced. Same behavior in both FCP 6.0.2 and FCE 4.0. That's right. You should be able to tell the host application that your view is as large as you want. Remember though, that users may get annoyed if it's really large and they have to constantly resize their parameter pane to see the whole thing. If you want to post the code from your -createViewForParm: method, I could see if there's anything obviously wrong with it. Are you creating the view in code or using a .nib file? _______________________________________________ Do not post admin requests to the list. They will be ignored. Pro-apps-dev mailing list (Pro-apps-dev@lists.apple.com <mailto:Pro-apps-dev@lists.apple.com>) Help/Unsubscribe/Update your Subscription: http://lists.apple.com/mailman/options/pro-apps-dev/pschneider%40apple.com This email sent to pschneider@apple.com This email sent to ses@vizrt.com This email sent to site_archiver@lists.apple.com