>> I am trying to understand the right way of dealing with a "settings" window >> in my application. I have a "Camera" object that wraps a Firewire video >> camera. I would like to bring up an NSPanel that enables various settings of >> the camera to be modified. I do not need to override any particular >> behaviours of NSWindowController, and it seems to me that logically my >> Camera object should not need to inherit from NSWindowController (the window >> business is a bit of a distraction from the main purpose of the camera >> class, which is handling received frames - and in future I may want more >> than one such camera-related window). >> ...
Shawn Bakhtiar wrote: > NSWindowController is for when you want to have multiple windows of the same > class (derived from NSWindow), but have different set of callbacks, in > different Window controllers that you can attach to each identical NSWindow, > in essence giving you a window class, that can have a different set of > callback functions. > > Question, why not just derive the camera class from NSWindow? There is no > programmatic need for NSWindowController, as an NSWindow is also an > NSResponder (can take all input). Interesting point, but I still feel this doesn't make a lot of logical sense because the camera is not a "type of window" (or indeed window controller) - plus, as I say, there's no reason I shouldn't have more than one different window associated with the camera... Quincey Morris wrote: > You're kind of mixing up two different tasks here. The Camera object is > (likely) part of your data model (in the MVC paradigm). A window controller > is a ... controller. For your settings window, you'll have least heartache if > you make the NIB's File's Owner a window controller. Window controllers are > *designed* to be the owners of NIB files. > > So, subclass NSWindowController, and add a "camera" property. (Your Camera > object can pass its 'self' pointer as a parameter to the window controller > subclass's init... method.) > > Then, to get at Camera properties, objects in the NIB can bind to File's > Owner.camera.whateverProperty -- instead of File's Owner.whateverProperty as > you have now. Ah, that is quite a neat solution - thanks for that. I hadn't twigged that I could do that sort of "property of a property" binding. It still seems a bit of a faff to create a controller subclass that isn't really doing anything other than passing through property requests, but at least I don't have do write accessors for every property I want to get at in the Camera object! Cheers Jonny_______________________________________________ Cocoa-dev mailing list (Cocoa-dev@lists.apple.com) 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: http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to arch...@mail-archive.com
