which…
/*
@briefProvides a place for window controllers that control transient
windows to "hang out" without being deallocced, so that you don't junk
up your app delegate with repeated boilerplate code and instance variables.
*/
Now any time I want a window controller to simpl
Thanks Kyle and Jerry.
It feels a bit strange to be adding extra glue code to track
otherwise-completely-autonomous windows (and controllers), but that has
certainly done the trick.
I found the static analyzer a bit odd to get used to - it sometimes gives
purportedly very detailed explanations
On 2013 Sep 13, at 12:11, Kyle Sluder wrote:
> Add a property to your app delegate that retains the window controller.
> Have your window controller listen for NSWindowDidCloseNotification from
> its window, and send a message to the app delegate. In response to this
> message, the app delegate
On 13 Sep 2013, at 17:12, Jonathan Taylor wrote:
>
>
> However the static analyzer complains that there is a "potential leak" of
> myWindowController, because it recognises that it has a retain count of 2
> when it returns from the init method. (The same applies if I don't retain in
> init a
On Fri, Sep 13, 2013, at 09:12 AM, Jonathan Taylor wrote:
> I want to allocate a window + controller, and I want it to live until the
> user closes the GUI window, at which point I want it to disappear and
> clean up after itself. I believe that the following code does not leak
> memory and behaves
This must be an incredibly basic question, but I haven't found an answer I'm
convinced by (apologies if I have missed something on the list). My question
relates to window controllers, and how ownership, retain/release etc should be
managed in order to (a) be correct and (b) satisfy
ib. It really doesn't matter. Window controllers are
> not mandatory.
>
> --Kyle Sluder
___
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
On Nov 28, 2012, at 9:22 AM, Randy Widell wrote:
> What are the best practices concerning connecting documents and window
> controllers?
>
> I understand that when I pop up a window related to a document, I need to add
> the window controller to the document with addW
What are the best practices concerning connecting documents and window
controllers?
I understand that when I pop up a window related to a document, I need to add
the window controller to the document with addWindowController:.
One thing I am not clear on is how to handle a modal sheet in
tion to First Responder anyway. The action
responder chain includes delegates of windows and the application, even though
they're not responders. Window controllers only get a shot at responding to
such an action because [if] they're the window's delegate. The app delegate is
al
gt;> that requires that the two window controllers have a common ancestor(?) in
>> the responder chain. That let's appDelegate out, not a responder object.
>
> Just wire the menu command directly to the app delegate object, instead of to
> First Responder.
>
> —Jens
On Aug 20, 2012, at 8:53 PM, Erik Stainsby wrote:
> My app has two windows, ergo two windowControllers. I would like to toggle
> between them from a single menu item, ergo a single method handler. However
> that requires that the two window controllers have a common ancestor(?)
This is either a stupid question or it is trivial. I just haven't run across
the situation before.
My app has two windows, ergo two windowControllers. I would like to toggle
between them from a single menu item, ergo a single method handler. However
that requires that the two w
Thanks to Mike Ash in an IRC chat, I believe I have the answer to this
particular question.
Memory Management Programming Guide - Weak References
http://developer.apple.com/library/mac/#documentation/Cocoa/Conceptual/MemoryMgmt/Articles/mmObjectOwnership.html#//apple_ref/doc/uid/2043
This seems like it should have an easy answer and one that I should know, but
my brain has frozen up on this and I cannot seem to determine if things are
working as expected or if there is something more I should be doing.
First, here is a sample project that demonstrates the behavior I am seein
On Dec 23, 2009, at 5:54 PM, Graham Cox wrote:
> On 24/12/2009, at 7:45 AM, David Blanton wrote:
>
>> In best Cocoa practices, should these Panels be owned by a window controller?
>
> Yes.
>
> --Graham
I have an Xcode project template that demonstrates a working document-based app
with a mai
On 24/12/2009, at 7:48 AM, David Blanton wrote:
> I meant should each Panel have a Window Controller.
Yes.
--Graham
___
Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)
Please do not post admin requests or moderator comments to the list.
Contact
I meant should each Panel have a Window Controller.
On Dec 23, 2009, at 1:45 PM, David Blanton wrote:
In my NSDocument app I have three Panels that will act as inspectors
for the document content.
In best Cocoa practices, should these Panels be owned by a window
controller?
db
__
On 24/12/2009, at 7:45 AM, David Blanton wrote:
> In best Cocoa practices, should these Panels be owned by a window controller?
Yes.
--Graham
___
Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)
Please do not post admin requests or moderator co
Please disregard my question about Window Controllers.
db
On Dec 23, 2009, at 1:48 PM, David Blanton wrote:
I meant should each Panel have a Window Controller.
On Dec 23, 2009, at 1:45 PM, David Blanton wrote:
In my NSDocument app I have three Panels that will act as
inspectors for the
In my NSDocument app I have three Panels that will act as inspectors
for the document content.
In best Cocoa practices, should these Panels be owned by a window
controller?
db
___
Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)
Please do not
Am Sa,27.09.2008 um 19:01 schrieb Daniel Child:
Hmm, well that seems to be the catch. I can't get the bindings to
work for the MOC.
First off, to set up the table displayed in the window loaded with a
separate nib file, I simply dragged in an "entity" object from the
Librarian. That doesn'
On Sep 27, 2008, at 10:01 AM, Daniel Child wrote:
but the tutorial online uses plain accessors (with the local copy of
MOC as an ivar, not a property) ... and works. One difference is
that their's is a doc-based CoreData app, and mine is not. But I
don't see why that should matter
It
Hmm, well that seems to be the catch. I can't get the bindings to work
for the MOC.
First off, to set up the table displayed in the window loaded with a
separate nib file, I simply dragged in an "entity" object from the
Librarian. That doesn't set up an MOC binding, but, following an on-
lin
On Fri, Sep 26, 2008 at 2:33 PM, Daniel Child <[EMAIL PROTECTED]> wrote:
> I tried this, but with Core Data, I'm getting a message that I need a
> managed object context (moc). I know how to get the moc, but I can't figure
> out who is calling for the moc in the first place. Something inside of the
To avoid cluttering up my main AppController (which had five windows),
I've started placing the individual windows into separate xib files.
Pre-Core Data (for a regular cocoa app), I would simply set up a
window controller, establish a reference to it in the main controller
(initWithWindowN
--- On Tue, 8/19/08, Sumner Trammell <[EMAIL PROTECTED]> wrote:
> Unless I'm being completely stupid about this, he could
> have done this, right?
>
> [[[self windowControllers] objectAtIndex:0]
> setShouldCascadeWindows:NO];
>
>
> Or better yet, this?
>
> [aController setShouldCascadeWi
On 19 Aug 2008, at 5:20 pm, Sumner Trammell wrote:
Hi, I'm trying to decipher someone else's code who is no longer
available. He did something that I think I can simplify, but I first
want to make sure I'm not being completely wrong-headed about what I'm
looking at.
First off, does this pers
ent.m file:
- (void)windowControllerDidLoadNib:(NSWindowController *)aController
{
NSWindow* window = [[[self windowControllers] objectAtIndex:0] window];
[[window windowController] setShouldCascadeWindows:NO];
.
.
.
}
In English:
He grabs a reference to the array of window
29 matches
Mail list logo
