> I have an NSWindowController/NSWindow Pair and I was wondering if I can
> easily present this as a Sheet?
>
> At the moment it works Ok as a regular window but have need of it as a sheet
> too in some cases and wondered about the best way of doing it?
Hi,
I have an NSWindowController/NSWindow Pair and I was wondering if I can easily
present this as a Sheet?
At the moment it works Ok as a regular window but have need of it as a sheet
too in some cases and wondered about the best way of doing it?
Thanks a lot
All the Best
Dave
On Oct 27, 2014, at 18:16 , Torsten Curdt wrote:
>
> I know - it smells horrible.
It doesn’t just smell, it’s actually wrong.
> My next thought was to just add
>
> - (id) initWithMyWindowNibPath:(NSString *)nibPath
> {
> return [super initWithWindowNibPath:nibPath owner:self];
e that the object returned by
> ‘[self alloc]’ is the same (or even the same class as) the object returned
> by ‘[controller init…]’.
>
I know - it smells horrible. Hence my post.
> I would try something like this:
>
> MyWC* myWC = [[My WC alloc] initWithWindow: nil];
>
(or even the same class as) the object returned by
‘[controller init…]’.
I would try something like this:
MyWC* myWC = [[My WC alloc] initWithWindow: nil];
NSWindowController* wc = [[NSWindowController alloc]
initWithWindowNibPath: nibPath owner: myWC];
myWC.window = wc.wind
I am a little confused on how to load NSWindowController from a bundle
other than the mainbundle.
While this code works just fine
controller = [[self alloc] initWithWindowNibName:@"TCAboutWindow"];
I now moved the the nib into it's own bundle inside the main bundle.
Since I c
> On Oct 19, 2014, at 02:14 , Quincey Morris
> wrote:
>
> Ugh! Now you made me create a project to try it.
Heh. Let's try this: Swift sucks; it can't make a million dollars appear on my
doorstep.
> Or maybe someone else has a better solution.
Yeah. Load my nib in -loadWindow ;-)
--
Rick
On Oct 19, 2014, at 01:28 , Rick Mann wrote:
>
>> you will need to declare it “convenience”.
>
> Tried that, too.
Ugh! Now you made me create a project to try it.
It looks like the problem is that ‘init’ is already a designated initializer,
though not of NSWindowController.
> On Oct 19, 2014, at 01:27 , Quincey Morris
> wrote:
>
>> On Oct 19, 2014, at 01:20 , Rick Mann wrote:
>>
>> I don't remember now, but I think it complained that I was overriding an
>> inherited method.
>
> Well, double-checking the syntax earlier in the chapter, you will need to
> declar
> On Oct 19, 2014, at 01:20 , Rick Mann wrote:
>
> I don't remember now, but I think it complained that I was overriding an
> inherited method.
Well, double-checking the syntax earlier in the chapter, you will need to
declare it “convenience”.
___
> On Oct 19, 2014, at 01:19 , Quincey Morris
> wrote:
>
> In short, take the “override” keyword off your declaration, and it should
> work exactly as you expected. (!)
I don't remember now, but I think it complained that I was overriding an
inherited method.
--
Rick Mann
rm...@latencyzero
On Oct 19, 2014, at 00:56 , Rick Mann wrote:
>
> The subclass initializer still has to initialize itself. It knows what the
> superclass initializer is doing, and it knows what it still needs to do.
> That's true even with the rules Swift currently imposes.
I don’t actually know what “initiali
s and don’t implement any designated initializers (you wouldn’t have to)
then it would be safe for a convenience one to call up to a superclass
convenience one. But now we have more rules and as soon as you do add a
property you need to initialize and thus have to add an initializer, your class
wo
> On Oct 19, 2014, at 00:54 , Quincey Morris
> wrote:
>
> If, hypothetically, a subclass was allowed to call any initializer in the
> superclass, then the result would be an object that was fully (“correctly”)
> initialized in terms of the superclass, but that doesn’t mean it’s fully
> initi
On Oct 19, 2014, at 00:24 , Rick Mann wrote:
>
> Well, I'm not sure I agree with that. Every initializer in a class should
> work correctly.
If, hypothetically, a subclass was allowed to call any initializer in the
superclass, then the result would be an object that was fully (“correctly”)
in
> On Oct 19, 2014, at 00:19 , Quincey Morris
> wrote:
>
> On Oct 18, 2014, at 23:46 , Rick Mann wrote:
>>
>> The rules on initializers don't make sense to me, in all honesty.
>
> Yes, but that tells us more about you than about Swift — specifically, it
> tells us that you’re more focused on
On Oct 18, 2014, at 23:46 , Rick Mann wrote:
>
> The rules on initializers don't make sense to me, in all honesty.
Yes, but that tells us more about you than about Swift — specifically, it tells
us that you’re more focused on what would ease your coding task in this one
case than on embracing
> On Oct 18, 2014, at 23:38 , Roland King wrote:
>
>
> The very first of those errors looks like you had the code in the wrong
> place, ie not within your class.
>
> Initialization is one of those Swift things which is uber-safe and thus very
> structured and hence in practice annoying.
>
ft:19:23:
> Expected parameter type following ':'
> /Users/rmann/Projects/XCAM/repo/XNC/trunk/XNC/CommConfig.swift:19:23:
> Expected ',' separator
> /Users/rmann/Projects/XCAM/repo/XNC/trunk/XNC/CommConfig.swift:21:1:
> 'required' initializer 'init(
mann/Projects/XCAM/repo/XNC/trunk/XNC/CommConfig.swift:21:1: 'required'
initializer 'init(coder:)' must be provided by subclass of 'NSWindowController'
If I instead call super.init(...), I get:
/Users/rmann/Projects/XCAM/repo/XNC/trunk/XNC/CommConfig.swift:19:3: Mu
meters is not a rule - typically
that's true but it's not a requirement and for many classes, definitely not
true.
--Graham
On 19 Oct 2014, at 2:08 pm, Rick Mann wrote:
> In Obj-C, I typically subclass NSWindowController and override -init to call
> -initWithNibName:. I do
In Obj-C, I typically subclass NSWindowController and override -init to call
-initWithNibName:. I do this so the caller doesn't have to worry about how to
make one of these window controllers:
@implementation MyWindowController
- (id) init
{
self = [super initWithWindowNibName: &quo
I subclass NSWindowController.
___
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
IGNATED_INITIALIZER, since it doesn't call one of super's designated
>> initializers.
>
> It doesn’t look like a bug per se, since the old NSWindowController pattern
> is grandfathered into the Swift world. However, tagging a subclass ‘init’ as
> designated will b
ted
> initializers.
It doesn’t look like a bug per se, since the old NSWindowController pattern is
grandfathered into the Swift world. However, tagging a subclass ‘init’ as
designated will break it.
I believe you can solve it if you implement ‘initWithWindow:’ as a designated
initializer in the
On Mon, 23 Jun 2014 18:14:05 -0700, Quincey Morris said:
>In that regard, ‘initWithWindowNibName:’ must be a designated
>initializer, since subclasses that don’t do their own nib loading have
>nothing else to call “up” to.
>
>I assume, therefore, that ‘initWithWindowNibName:’ is marked as a
>desig
On 24 Jun 2014, at 2:33 pm, Quincey Morris
wrote:
> Sorry, I wasn’t carping at you
Nor I at you - I was just curious as to how the discussion suddenly veered over
into Swift.
> Because Swift is codifying and enforcing Objective-C's designated initializer
> pattern. Similar enforcement in O
On Jun 23, 2014, at 8:16 PM, Graham Cox wrote:
> On 24 Jun 2014, at 11:14 am, Quincey Morris
> wrote:
>> Actually, I understood the thrust of Sean’s question as being that
>> NSWindowController’s initializers don’t follow Swift rules.
>
> Well, Swift wasn't mentioned at all in the OP, but this
one it for years.
Hence my speculation that it was Swift’s greater formalism that got Sean
thinking about this. Speculation only. Anyway, I believe Roland’s answer is
correct: Swift has a loophole that lets the NSWindowController init pattern
work there
On 24 Jun 2014, at 11:14 am, Quincey Morris
wrote:
> Actually, I understood the thrust of Sean’s question as being that
> NSWindowController’s initializers don’t follow Swift rules.
>
Well, Swift wasn't mentioned at all in the OP, but this was:
> The Obj-C designated initializer rules say
On 24 Jun, 2014, at 9:14 am, Quincey Morris
wrote:
> On Jun 23, 2014, at 17:30 , Graham Cox wrote:
>
>> I interpret that to mean it must call a designated initializer *eventually*,
>> not necessarily directly. Since all -initXXX methods of the superclass must
>> call the superclass's design
On Jun 23, 2014, at 17:30 , Graham Cox wrote:
> I interpret that to mean it must call a designated initializer *eventually*,
> not necessarily directly. Since all -initXXX methods of the superclass must
> call the superclass's designated initializer, your subclass's D.I. can call
> any of the
On 24 Jun 2014, at 3:38 am, Sean McBride wrote:
> The Obj-C designated initializer rules say that if a subclass creates a new
> designated initializer that its implementation must call (one of) the
> superclass' designated initializer.
>
> The docs for NSWindowControlle
On Jun 23, 2014, at 11:38 AM, Sean McBride wrote:
> Hi all,
>
> The Obj-C designated initializer rules say that if a subclass creates a new
> designated initializer that its implementation must call (one of) the
> superclass' designated initializer.
>
> The docs
On 23 Jun 2014, at 14:38, Sean McBride wrote:
> Hi all,
>
> The Obj-C designated initializer rules say that if a subclass creates a new
> designated initializer that its implementation must call (one of) the
> superclass' designated initializer.
>
> The docs
Hi all,
The Obj-C designated initializer rules say that if a subclass creates a new
designated initializer that its implementation must call (one of) the
superclass' designated initializer.
The docs for NSWindowController say initWithWindow: is the (only) designated
initializer.
Coun
Anyone have awesome templates to share? :)
Eric Shepherd
Sent from my iPhone
> On Jun 8, 2014, at 9:04 PM, Shane Stanley wrote:
>
>> On 9 Jun 2014, at 10:16 am, Graham Cox wrote:
>>
>> I really wish Xcode would allow us to make our own templates, even for NSxxx
>> classes.
>
> You can. Copy
On 9 Jun 2014, at 11:04 am, Shane Stanley wrote:
> You can.
Thanks! There's my morning's productivity gone, but I fully expect it to pay
itself back.
--Graham
___
Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)
Please do not post admin requ
On 9 Jun 2014, at 10:16 am, Graham Cox wrote:
> I really wish Xcode would allow us to make our own templates, even for NSxxx
> classes.
You can. Copy this:
/Applications/Xcode.app/Contents/Developer/Library/Xcode/Templates/File
Templates/Cocoa/Objective-C class.xctemplate
To here:
~/Librar
On Jun 8, 2014, at 8:16 PM, Graham Cox wrote:
>
>
>> On 8 Jun 2014, at 7:32 am, Lee Ann Rucker wrote:
>>
>> Delete that init method. Xcode has a standard template and doesn't change it
>> when you tick the "make a xib file" checkbox.
>
>
> I really wish Xcode would allow us to make our own
On 8 Jun 2014, at 7:32 am, Lee Ann Rucker wrote:
> Delete that init method. Xcode has a standard template and doesn't change it
> when you tick the "make a xib file" checkbox.
I really wish Xcode would allow us to make our own templates, even for NSxxx
classes. The templates they do come wit
wrote:
> Okay, if I create a new NSWindowController subclass (and tell Xcode to
> generate the .xib as well), it gives me simple (too simple, I think) template
> code, whose init... method takes an NSWindow reference. Where does this come
> from (the reference)?
>
> • Is the code
ind some useful sample and start modifying it.
- Original Message -
From: "William Squires"
To: "Cocoa Developers"
Sent: Saturday, June 7, 2014 12:24:02 PM
Subject: Another dumb question about NSWindowController(s)
Okay, if I create a new NSWindowController subclass (and t
Okay, if I create a new NSWindowController subclass (and tell Xcode to
generate the .xib as well), it gives me simple (too simple, I think) template
code, whose init... method takes an NSWindow reference. Where does this come
from (the reference)?
• Is the code instantiating the custom
Hi and thanks for your answers.It was a problem with cocoapods. I
don't know why but even after reinstalling, the script "add Pods resources" was
not in the build phases.I added it manually, and now it works.
___
Cocoa-dev mailing list (Cocoa-dev@lists
On Apr 18, 2014, at 14:14 , Gerd Knops wrote:
> Dangerous (and entirely wrong) assumption.
I know perfectly well that Mac HFS+ can be made case sensitive, so perhaps I
should have worded it better: “…even *when* the Mac file system is case
insensitive.”
However, both you and Fritz missed my r
Oh, also, HFS+ is case-sensitive in iOS, lacking NSWindowController though it
be.
(Is it HFS+? I’m too eager to get out the door for me to check.)
— F
On 18 Apr 2014, at 5:30 PM, Fritz Anderson wrote:
> To be less Hermetic… case-sensitivity has been an option in HFS+ installat
To be less Hermetic… case-sensitivity has been an option in HFS+ installation
for many, many years.
I think you’d be ill-advised to pick it, as I am confident that there is a
large codebase that inadvertently depends on case-insensitivity. (That is, the
developer sometimes opened "Polish.dat",
Dangerous (and entirely wrong) assumption.
On Apr 18, 2014, at 12:07 PM, Quincey Morris
wrote:
> — Check the capitalization of your XIB file name. It’s possible that case
> matters to nib loading, even though the Mac file system is case insensitive.
>
___
On Apr 18, 2014, at 06:32 , Colas wrote:
> —> in my real project, I have an error :
> -[MyCBDLockManager loadWindow]: failed to load window nib file
> 'MyCBDLockManager’.
In regards to CocoaPods issues, this list isn’t the place to ask.
In regards to nib-loading issues:
— Check the capitaliza
do |sss|
sss.source_files = 'Classes/Auxiliary
classes/MyCBDSafeguardManager/**/*.{h,m}'
end
end
s.resource = "Classes/help_MyCBD_BSManagedDocument.rtf"
s.dependency 'BSManagedDocument', '~>0.3.2'
s.dependency 'CBDFoundationTo
If you own an app which overrides -[NSWindowController
windowTitleForDocumentDisplayName:] to provide a custom document window title,
for example, to append a suffix, it probably has a little break in 10.9…
1. Create a new document.
2. Click in the menu: File > Duplicate. A new win
On Sep 26, 2012, at 18:10 , Jeff Johnson
wrote:
> Is your app distributed as a zip file?
>
> I had a similar bizarre issue with NSBundle a number of months ago, and it
> turned out that the problem occurred when the app was unzipped using The
> Unarchiver. Unzipping with the built-in Archive
On Sep 26, 2012, at 12:51 PM, Quincey Morris wrote:
> On Sep 26, 2012, at 10:08 , Kyle Sluder wrote:
>
>> Can you log +[NSBundle allBundles] and/or use Instruments to see what file
>> access Foundation is performing and what responses it's getting back?
>
> The difficulty is that this exceptio
On 26 Sep 2012, at 17:37, Quincey Morris
wrote:
> On Sep 25, 2012, at 22:37 , Graham Cox wrote:
>
>> Is the app sandboxed?
>>
>> I ask because I've had reports of this same error from the odd user but have
>> been unable to reproduce it so far. It's ONLY happening since we sandboxed
>> tho
On Sep 26, 2012, at 10:08 , Kyle Sluder wrote:
> Can you log +[NSBundle allBundles] and/or use Instruments to see what file
> access Foundation is performing and what responses it's getting back?
The difficulty is that this exception has never happened to me during
development. By chance (mayb
On Sep 26, 2012, at 9:37 AM, Quincey Morris
wrote:
>
> It's as if there's a short asynchronous step in finding bundles, which leaves
> a small timing window for failure that depends on the code order. I dunno.
That would be really weird and unfortunate. Can you log +[NSBundle allBundles]
and
On Sep 25, 2012, at 22:37 , Graham Cox wrote:
> Is the app sandboxed?
>
> I ask because I've had reports of this same error from the odd user but have
> been unable to reproduce it so far. It's ONLY happening since we sandboxed
> though.
No, the app has been around for a while and isn't sandb
On 26/09/2012, at 12:35 PM, Quincey Morris
wrote:
> Anyone have an idea what's going on here, and what I should really do to
> avoid/fix the problem?
Is the app sandboxed?
I ask because I've had reports of this same error from the odd user but have
been unable to reproduce it so far. It's
Here's an except of some code in a window controller:
> - (id) init {
> self = [super initWithWindowNibName: @"MyWindow"];
> …
> return self;
> }
>
> + (MyWinController*) myWinController {
> return [[MyWinController alloc] init];
> }
The key point here is that the MyWinCo
On 24 May 2012, at 16:27, Kyle Sluder wrote:
>> 1. If I do not set B's pointer to A, both A and B are deallocated correctly
>> 2. If instead I set B's pointer to A, but reset it to nil just before B is
>> closed, both A and B are deallocated correctly
>> 3. If instead B still has a live pointer to
is 8 years old, so I would
> have hoped this would be sorted by now(!), but it does sound remarkably close
> to my scenario here.
NSAutounbinder is part of the solution to the problem noted at that blog.
NSWindowController has special logic to break the retain cycle inherent in
binding throu
On May 24, 2012, at 10:26 AM, Jonathan Taylor wrote:
> I have been battling a retain cycle for a couple of hours, assuming I am at
> fault, but I am starting to think there is something fishy going on. Can
> anybody advise?
>
> - I have a window controller subclass (and associated window) A, a
On May 24, 2012, at 10:21 AM, Fritz Anderson wrote:
> On 24 May 2012, at 9:26 AM, Jonathan Taylor wrote:
>
>> - I have a window controller subclass (and associated window) A, and a
>> separate window controller subclass (and associated window) B. B contains a
>> property, designated 'retain', t
On 24 May 2012, at 9:26 AM, Jonathan Taylor wrote:
> - I have a window controller subclass (and associated window) A, and a
> separate window controller subclass (and associated window) B. B contains a
> property, designated 'retain', that keeps a pointer to A. B is
> programatically closed fir
I have been battling a retain cycle for a couple of hours, assuming I am at
fault, but I am starting to think there is something fishy going on. Can
anybody advise?
- I have a window controller subclass (and associated window) A, and a separate
window controller subclass (and associated window)
ote:
> > On Apr 11, 2012, at 7:04 AM, Rui Pacheco wrote:
> >
> > > Hi,
> > >
> > > I have an NSWindowController that creates an instance of
> > > NSManagedObjectContext. That window controller loads a NIB that has a
> table
> > > populated
r is using the same MOC that you use
in your -init and -windowDidLoad?
> On 11 April 2012 19:12, Keary Suska wrote:
> On Apr 11, 2012, at 7:04 AM, Rui Pacheco wrote:
>
> > Hi,
> >
> > I have an NSWindowController that creates an instance of
> > NSManagedObjectConte
gt; Hi,
> >
> > I have an NSWindowController that creates an instance of
> > NSManagedObjectContext. That window controller loads a NIB that has a
> table
> > populated by an NSArrayController bound to the MOC in the window
> > controller. This was done via Interface Bu
On Apr 11, 2012, at 7:04 AM, Rui Pacheco wrote:
> Hi,
>
> I have an NSWindowController that creates an instance of
> NSManagedObjectContext. That window controller loads a NIB that has a table
> populated by an NSArrayController bound to the MOC in the window
> controller.
Hi,
I have an NSWindowController that creates an instance of
NSManagedObjectContext. That window controller loads a NIB that has a table
populated by an NSArrayController bound to the MOC in the window
controller. This was done via Interface Builder. The array controller is
set to retrieve
On Aug 29, 2011, at 6:13 PM, Jens Alfke wrote:
> On Aug 29, 2011, at 3:51 PM, koko wrote:
>
>> I have created a nib which contains a window. I have set the File's Owner to
>> NSWindowController.
>> I have connected the window outlet of File's Owner to
On Aug 29, 2011, at 3:51 PM, koko wrote:
> I have created a nib which contains a window. I have set the File's Owner to
> NSWindowController.
> I have connected the window outlet of File's Owner to the window defined in
> the nib.
Don’t forget to wire the window’s del
I have created a nib which contains a window. I have set the File's Owner to
NSWindowController.
I have connected the window outlet of File's Owner to the window defined in the
nib.
I do this:
NSWindowController *wc = [[NSWindowController alloc]
initWithWindowNibName:@"
sure what's going on, I have my NSWindowController subclass declared as:
>>
>> @interface MainWindowController : NSWindowController
>>
>> and have a property (and ivar) in my NSViewController subclass:
>>
>> @property (assign) MainWindowController *wi
On Jul 23, 2011, at 12:29 PM, Andre Masse wrote:
> So, in MasterDetailController, if I call:
>
> [[[windowController window] contentView] setNeedsDisplay:YES];
>
> I get the warning:
>
> 'window' maybe deprecated because receiver type is unknown
What’s the type of the local variable ‘windowC
Make sure you import all the required headers (especially the one defining
MainWindowController).
Le 23 juil. 2011 à 21:29, Andre Masse a écrit :
> Not sure what's going on, I have my NSWindowController subclass declared as:
>
> @interface MainWindowController : NSWindowControl
Not sure what's going on, I have my NSWindowController subclass declared as:
@interface MainWindowController : NSWindowController
and have a property (and ivar) in my NSViewController subclass:
@property (assign) MainWindowController *windowController;
So, in MasterDetailController,
On Jul 23, 2011, at 7:50 AM, Andre Masse wrote:
> Hi,
>
> Got this warning in Xcode 4.1 on Lion. Is this really deprecated? There's no
> indication in NSWindowController header…
Are you sure the object is typed as an NSWindowController and not an id or
something else? -[N
Hi,
Got this warning in Xcode 4.1 on Lion. Is this really deprecated? There's no
indication in NSWindowController header…
Thanks,
Andre Masse___
Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)
Please do not post admin requests or mode
I like the independence of the window controller being up to
>> clean up after itself. It's also a lot less code.
>>
>> Hope this helps
>> Marc
>>
>>> Hello.
>>>
>>> I'm building a Cocoa application and have a question about using
plication and have a question about using
>> window controllers. The idea is that when the user selects New from
>> the File menu, an instance of MyWindowController which is a subclass
>> of NSWindowController is created and a new window from MyWindow.xib is
>> displayed.
>&g
building a Cocoa application and have a question about using
> window controllers. The idea is that when the user selects New from
> the File menu, an instance of MyWindowController which is a subclass
> of NSWindowController is created and a new window from MyWindow.xib is
> displ
On Jun 18, 2011, at 12:27 PM, Matt Neuburg wrote:
>
> On Jun 18, 2011, at 12:02 PM, cocoa-dev-requ...@lists.apple.com wrote:
>
>> Date: Sat, 18 Jun 2011 10:09:13 -0700
>> From: Kyle Sluder
>> Subject: Re: Release a NSWindowController after the window is closed
>
Jun 2011 10:09:13 -0700
>> From: Kyle Sluder
>> Subject: Re: Release a NSWindowController after the window is closed
>
>> This general pattern will fail under ARC (yay, we can talk about that
>> now).
>
> Why are we able to do that? m.
> ___
Matt Neuburg wrote:
Why are we able to do that? m.
Because ARC is public knowledge:
http://clang.llvm.org/docs/AutomaticReferenceCounting.html
-- GG
___
Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)
Please do not post admin requests or m
On Jun 18, 2011, at 12:02 PM, cocoa-dev-requ...@lists.apple.com wrote:
> Date: Sat, 18 Jun 2011 10:09:13 -0700
> From: Kyle Sluder
> Subject: Re: Release a NSWindowController after the window is closed
> This general pattern will fail under ARC (yay, we can talk about that
> now
:] documentation, "To remove a
window controller from the list of active controllers, send it the
NSWindowController message close." That implies that
NSWindowController is in charge of removing itself from the document's
list of window controllers. My instinct is t
On Wed, Jun 15, 2011 at 11:40 AM, Brian Norh wrote:
> I'm building a Cocoa application and have a question about using
> window controllers. The idea is that when the user selects New from
> the File menu, an instance of MyWindowController which is a subclass
> of NSWindowCont
On Jun 15, 2011, at 11:40, Brian Norh wrote:
> Is there a better way to do this? I have searched the documentation
> and have not found anything specific on which practices to use. It
> sounds like something very basic which it should cover so maybe I'm
> just searching with the wrong terms.
I'm
Hello.
I'm building a Cocoa application and have a question about using
window controllers. The idea is that when the user selects New from
the File menu, an instance of MyWindowController which is a subclass
of NSWindowController is created and a new window from MyWindow.xib is
displayed.
On 29/04/2011, at 00:17, Alexander Spohr wrote:
>> I have a document-based app which loads a couple of NSWindowController
>> subclasses. That's fine. In one of the subclasses, I load a nib with a
>> NSView subclass. It wants to access one of the instance vars in th
On Apr 28, 2011, at 04:28, Ben Golding wrote:
> In the window that's loaded from Face.xib, there's a custom view
> (SundialView) which needs to access the sundial instance variable in File's
> Owner. I just don't seem to be able to control-drag in some order to hook
> them up and I think I sho
Am 28.04.2011 um 13:28 schrieb Ben Golding:
> I have a document-based app which loads a couple of NSWindowController
> subclasses. That's fine. In one of the subclasses, I load a nib with a
> NSView subclass. It wants to access one of the instance vars in the window
> co
I feel like I should be able to figure this out but I feel like I'm going
around circles. I've looked through the mailing list and can't find anything
similar (but I might be searching using the wrong terms).
I have a document-based app which loads a couple of NSWindowControl
m_designViewerController = [[[NSWindowController alloc]
initWithWindowNibName:@"DesignViewer"] retain];
___
Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)
Please do not post admin requests or moderator comments to the list.
Contact the mod
OK. My error was not setting Files Owner to NSWindowController which let me
now set Files Owner window to my window.
-koko
On Feb 26, 2011, at 12:25 AM, koko wrote:
> Apparently something else is going on ...
>
> 1 m_designViewerController = [[[NSWindowControl
Apparently something else is going on ...
1 m_designViewerController = [[[NSWindowController alloc]
initWithWindowNibName:@"DesignViewer"] retain];
2 [m_designViewerController showWindow:self];
3 NSWindow *window = [m_designViewerController window];
4
I recently ot bit by this. it seems that the window will only be allocated when
you call showWindow. Just reorder you sequence.
On 2011-02-26, at 01:58 , koko wrote:
> I have a xib in which is defined a NSPanel
>
> In code I do
>
> m_designViewerController = [[[NSWindowC
I have a xib in which is defined a NSPanel
In code I do
m_designViewerController = [[[NSWindowController alloc]
initWithWindowNibName:@"DesignViewer"] retain];
NSWindow *window = [m_designViewerController window];
[window setDel
1 - 100 of 226 matches
Mail list logo
