On Thu, 31 Jul 2014 09:26:27 -0700, Jerry Krinock said:
One thing I just noticed is that NSWindowController's 'document'
property is not actually documented as KVO-compliant. Maybe that's my
problem... but I've been binding through it for over a decade now!
That may well be the real problem,
On Aug 1, 2014, at 10:33 AM, Sean McBride s...@rogue-research.com wrote:
On Thu, 31 Jul 2014 09:26:27 -0700, Jerry Krinock said:
One thing I just noticed is that NSWindowController's 'document'
property is not actually documented as KVO-compliant. Maybe that's my
problem... but I've been
On 2014 Aug 01, at 10:33, Sean McBride s...@rogue-research.com wrote:
I've tried some similar permutations and they have 'fixed' the issue. I have
about 50 xibs to fix now, so want to be sure I do this correctly. :) I now
find myself questioning basic things. :)
I understand. It would
On Aug 1, 2014, at 12:03 , Jerry Krinock je...@ieee.org wrote:
Unfortunately, I’m not able to justify my design pattern based on the Cocoa
Bindings API documentation.
As I said earlier in the thread, that fact that the error messages go away
doesn’t mean the problem doesn’t exist. However, I
On Wed, 30 Jul 2014 15:45:04 -0500, Ken Thomases said:
A zeroing weak property changes without emitting KVO change
notifications. Therefore, it's not KVO-compliant. Basically, weak
properties are incompatible with KVO and bindings.
Ouch! Didn't realise that. That's pretty annoying, as weak
On 2014 Jul 31, at 09:05, Sean McBride s...@rogue-research.com wrote:
One thing I just noticed is that NSWindowController's 'document' property is
not actually documented as KVO-compliant. Maybe that's my problem... but
I've been binding through it for over a decade now!
That may well be
On Jul 31, 2014, at 09:05 , Sean McBride s...@rogue-research.com wrote:
Other than use of 'weak', how else might something be changed in a
non-KVO-compliant manner in ARC but not GC? Again, the error is only in ARC
and not GC.
I’m not sure this is the most productive way to approach this.
:
document.managedObjectContext, Options: New: NO, Old: NO, Prior: NO Context:
0x0, Property: 0x10ee1ac10
I have:
- a nib who's File's Owner is an NSViewController subclass
- an NSObjectController at the top-level of my nib
- a strong IOOutlet from my NSViewController to the NSObjectController
with it.
NSKeyValueObservance 0x107985ad0: Observer: 0x107985810, Key path:
document.managedObjectContext, Options: New: NO, Old: NO, Prior: NO
Context: 0x0, Property: 0x10ee1ac10
I have:
- a nib who's File's Owner is an NSViewController subclass
- an NSObjectController at the top-level of my nib
On Jul 30, 2014, at 13:33 , Sean McBride s...@rogue-research.com wrote:
File's Owner (my NSViewController subclass) responds to 'windowController'
because I have a vanilla synthesized weak property relating my
NSViewController to its containing window's controller.
This is the problem. Weak
Owner of the NSWindow in IB to NSWindowsController.
Why i have to do that, and what is the File's Owner by the way?
___
Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)
Please do not post admin requests or moderator comments to the list.
Contact
in stackoverflow revealed me that it happens that way because i
have to set the File's Owner of the NSWindow in IB to NSWindowsController.
Whether a window will appear or not has nothing to do with File's Owner. Your
window is probably marked as Release When Closed in IB. It's shown once
On Jun 8, 2014, at 12:23 PM, Seth Willits sli...@araelium.com wrote:
Whether a window will appear or not has nothing to do with File's Owner. Your
window is probably marked as Release When Closed in IB. It's shown once the
first time, but after closing it it's deallocated and no longer
was File's
Owner and you passed nil for the owner when you loaded the NIB. You just
told the NIB-loading machinery to connect the window to nothing.
That doesn't seem to be the case, because it does work.
In any case, it seems totally backward to me that you would choose a NIB name
to load
On May 23, 2014, at 19:34:10, Graham Cox graham@bigpond.com wrote:
If what you're really trying to do is to store a class in the nib such that
you can use that to instantiate the right kind of object for FO, I would say
that you're doing it wrong (™). What you probably want is some way
the NIB won't have a controller if the controller was File's
Owner and you passed nil for the owner when you loaded the NIB. You just
told the NIB-loading machinery to connect the window to nothing.
That doesn't seem to be the case, because it does work.
Then the window's controller is some real
a method or
property for the file's owner, the best way I know of to get this is to look
for the window in the nib (see function below), gets its controller, get the
controller's class, then release the window so we can create things in our
normal way.
If there some better way to get the file's owner
, but now we need to do this. Since NSNib doesn't have a method or
property for the file's owner, the best way I know of to get this is to look
for the window in the nib (see function below), gets its controller, get the
controller's class, then release the window so we can create things in our
subclass in
the xib, but now we need to do this. Since NSNib doesn't have a method or
property for the file's owner, the best way I know of to get this is to look
for the window in the nib (see function below), gets its controller, get the
controller's class, then release the window so we can
On Dec 2, 2010, at 1:47 AM, Quincey Morris wrote:
On Dec 1, 2010, at 11:08, Mikkel Eide Eriksen wrote:
See line 48 onwards below:
http://code.google.com/p/cocoa-gedcom/source/browse/trunk/GCCoreData/src/GCDocument.m
(there are probably lots of terribly ugly non-Cocoa things in here, I'm
Well I feel a little dumb now. After lots of debugging and digging at values
that looked correct everywhere, checking object creating again again, and
what not, It turns out I forgot to actually redraw the window:
[[[self loadingWindowController] window] display];
Everything worked all along
On Wed, Dec 1, 2010 at 10:09 AM, Mikkel Eide Eriksen
mikkel.erik...@gmail.com wrote:
Well I feel a little dumb now. After lots of debugging and digging at values
that looked correct everywhere, checking object creating again again, and
what not, It turns out I forgot to actually redraw the
On Dec 1, 2010, at 7:41 PM, Kyle Sluder wrote:
On Wed, Dec 1, 2010 at 10:09 AM, Mikkel Eide Eriksen
mikkel.erik...@gmail.com wrote:
Well I feel a little dumb now. After lots of debugging and digging at values
that looked correct everywhere, checking object creating again again, and
what
On Dec 1, 2010, at 11:08, Mikkel Eide Eriksen wrote:
See line 48 onwards below:
http://code.google.com/p/cocoa-gedcom/source/browse/trunk/GCCoreData/src/GCDocument.m
(there are probably lots of terribly ugly non-Cocoa things in here, I'm only
just starting out and come from a mostly
On Nov 30, 2010, at 5:34 PM, Quincey Morris wrote:
On Nov 29, 2010, at 21:36, Mikkel Eide Eriksen wrote:
I'm updating the objectCount property during readFromURL:ofType:error: -
could that be it?
No, that's a suitable method, but the question is whether it's running in the
main thread
];
This is to provide bindings for various things, such as the title of the
loading window:
bound to: File's Owner (LoadingWindowController)
Model Key Path: document.displayName
Display Pattern: Loading %{titl...@...
This displays correctly.
Document also has a number of int counters to display the progress
Mikkel Eide Eriksen mailto:mikkel.erik...@gmail.com wrote
(Monday, November 29, 2010 6:00 AM +0100):
When reading a file, my Document object tells LoadingWindowController to show
its window [loadingWindowController setDocument:self];
I'm not sure this is your problem (and I'm sure someone
James Bucanek mailto:subscri...@gloaming.com wrote (Monday,
November 29, 2010 8:37 AM -0700):
Basically, if I add an observer using the path document.someProperty, KVO
attaches the observer to the the someProperty object, not document. So if I
change it (document.someProperty = newProperty),
I don't think I'm replacing the document per se. In my NSDocument init
override, I do this (only relevant parts copied):
if (![self loadingWindowController])
[self setLoadingWindowController:[[MyLoadingWindowController alloc]
init]];
[[self loadingWindowController] setDocument:self];
I just tried properly adding the loadingWindowController to NSDocument's
windowControllers without any luck. Then I tried moving the @property
objectCount to my loadingWindowController and updating it from NSDocument:
[[self loadingWindowController] setObjectCount:[[self
Mikkel Eide Eriksen mailto:mikkel.erik...@gmail.com wrote
(Monday, November 29, 2010 10:00 AM +0100):
[[self loadingWindowController] setObjectCount:[[self loadingWindowController]
objectCount]+1];
Still no go on the interface (I can tell via logs that controller.objectCount
is incrementing
On Nov 29, 2010, at 08:10, Mikkel Eide Eriksen wrote:
Reading up on the documentation, I guess what I should do in my Document init
is this:
if (![self loadingWindowController])
[self setLoadingWindowController:[[MyLoadingWindowController alloc]
init]];
[self
On Nov 30, 2010, at 3:18 AM, Quincey Morris wrote:
On Nov 29, 2010, at 08:10, Mikkel Eide Eriksen wrote:
Reading up on the documentation, I guess what I should do in my Document
init is this:
if (![self loadingWindowController])
[self
On Nov 29, 2010, at 21:36, Mikkel Eide Eriksen wrote:
I'm updating the objectCount property during readFromURL:ofType:error: -
could that be it?
No, that's a suitable method, but the question is whether it's running in the
main thread or if the document initialization process got switched to
.
Window controllers don't belong in nibs. You create them in code and
ask them to load a nib, at which point they fill in as File's Owner
(unless you use the variant in which you provide a different File's
Owner, but you almost never actually want to use that).
That's my problem, I want to create
a
WindowController object and a Window object in a new empty NIB.
Window controllers don't belong in nibs. You create them in code and
ask them to load a nib, at which point they fill in as File's Owner
(unless you use the variant in which you provide a different File's
Owner, but you almost never actually
and display the Identity Inspector.
3. Set the class to that of your custom window controller.
4. Now hook up your nib targets and actions to the File's Owner.
The problem is precisely 4), how do I move all the connections (like
80 or more) that were done between WindowController and Window, so
On 5 Mar 2010, at 12:23, David Geldreich wrote:
1. Decompose your monster nib as required.
2. In IB select Files's Owner and display the Identity Inspector.
3. Set the class to that of your custom window controller.
4. Now hook up your nib targets and actions to the File's Owner
Hello,
I am refactoring one big NIB file into smaller pieces. I copy/paste a
WindowController object and a Window object in a new empty NIB.
I end up having
File's Owner
First Responder
Application
WindowController
Window
I would like to move WindowController as File's Owner and keep all
to load a nib, at which point they fill in as File's Owner
(unless you use the variant in which you provide a different File's
Owner, but you almost never actually want to use that).
--Kyle Sluder
___
Cocoa-dev mailing list (Cocoa-dev@lists.apple.com
On Aug 13, 2009, at 1:59 PM, Dave Carrigan wrote:
On Aug 13, 2009, at 1:32 PM, Michael de Haan wrote:
The inspector of File's owner in the Custom xib shows, as
expected an outlet ( which is connected) as well as the method
showPanel which is *not* connected. In fact, I am unable
target is established in the
MainMenu.xib ( ie About NewApplication is connected to the method
showPanel).
The About _menu_'s target is established in the MainMenu.xib. The
About _window_ is not known in the scope of this xib.
Secondly, in the About.xib the File's owner is set
I meant but syntax is
important :-)
Secondly, in the About.xib the File's owner is set to the
AppController AND File's owner aboutWindow outlet is now pointed
to the NSPanel object.
I am assuming that this second action is used in the method of
showPanel, where I assume
On Aug 13, 2009, at 8:26 PM, Ken Thomases wrote:
I think I finally get File's owner :-) So, if I understand you
correctly, having set File's owner to the appropriate class ( in
this case AppController) I set the appropriate **proxy** outlet of
File's owner to the object
On Apr 15, 2009, at 2:08 PM, Sidney San Martín wrote:
I want to hook up actions and bindings in a nib (loaded with
+[NSBundle loadNibNamed:owner:]) to an object other than File's Owner
(one which will already exist when the nib is loaded). Can I create a
reference to a second object
I want to hook up actions and bindings in a nib (loaded with
+[NSBundle loadNibNamed:owner:]) to an object other than File's Owner
(one which will already exist when the nib is loaded). Can I create a
reference to a second object in Interface Builder without causing it
to be instantiated and hook
I have a nib-file with the File's Owner class set to my own subclass of
NSViewController. The nib-file also contains a custom view with a button whose
target and action is set to a method in File's Owner.
The trouble is that I get EXC_BAD_ACCESS when I click the button and it tries
to call my
On Oct 7, 2008, at 2:34 PM, Andreas Eriksson wrote:
I guess I have misunderstood something here. Is there something
special about
File's Owner that prevents this from working?
There's not enough information here to answer your question. You
should post:
1 - How you instantiate your
I guess I have misunderstood something here. Is there something special
about
File's Owner that prevents this from working?
There's not enough information here to answer your question. You should
post:
1 - How you instantiate your custom NSViewController class and load the nib.
2
Hi
I'm trying to bind double click actions of an NSTableView to file's
owner and can't figure out exactly how to set them up. My file's
owner has a double click handler defined like so:
- (void) handleDoubleClick:(NSNumber *) inRowIndex;
Given that, how would I set up the bindings
Hi
My file's owner class has a method to return a file icon but I'm
finding that when I do the following, it reverts back to shared user
defaults whenever I select other things in the user interface.
Here are my bind settings
Value
Bind to: file's owner
Model Key Path
After two more hours of futzing, I find that I can't bind any
controllers to file's owner. I can bind some of the gui object values
directly to files owner but controllers always unbind spontaneously
whenever I click on another object in the interface and back to the
controller. What could
On Oct 4, 2008, at 8:16 PM, Quincey Morris wrote:
After you choose File's Owner from the popup, and type the model key
in the text field below, press Return or Tab, and verify that the
check mark next to File's Owner has become checked. If you click
away without committing the edit
window, etc. are in MyDocument.nib.
I can't control-drag from my new menu item in MainMenu.nib to the
File's Owner object in MyDocument.nib. It makes sense to me that I
can't, but it never occurred to me that I couldn't. Does that make
sense?
I'm not sure what to do to reshape my design. Would
the Xcode document-based app
template, now needs a new item added to its File menu.
Menu items are, of course, in MainMenu.nib, and the rest of the app's
widgets, like the main window, etc. are in MyDocument.nib.
I can't control-drag from my new menu item in MainMenu.nib to the
File's Owner
I've got a class, let's call it Foo, that loads a NIB called Bar. In IB, the
File's owner of Bar is set to class Foo. When Foo loads Bar, passing self as
the file's owner, Foo.awakeFromNib gets called during the nib loading process.
Is that meant to happen? It doesn't make sense to me
On Aug 4, 2008, at 11:38 PM, Chris Idou wrote:
I've got a class, let's call it Foo, that loads a NIB called Bar.
In IB, the File's owner of Bar is set to class Foo. When Foo loads
Bar, passing self as the file's owner, Foo.awakeFromNib gets called
during the nib loading process
appropriate here.
That's not good either. Root object has a special meaning in the
context of archiving graphs of objects. In particular, it's one of
the archived objects, whereas File's Owner is by definition not one of
the objects in the nib.
On May 27, 2008, at 07:06, Andy Lee wrote:
You
On May 27, 2008, at 11:50, Andy Lee wrote:
That's not good either. Root object has a special meaning in the
context of archiving graphs of objects. In particular, it's one of
the archived objects, whereas File's Owner is by definition not one
of the objects in the nib.
Yes.
I
On May 27, 2008, at 3:40 PM, Quincey Morris wrote:
Putting this the other way round, I'm not sure that the answer is
to give File's Owner or Nib's Loader behavior that justifies its
name, but rather to give it a unobjectionable name that justifies
its (lack of) behavior -- if anyone can
On May 27, 2008, at 4:40 PM, Quincey Morris wrote:
On May 27, 2008, at 11:50, Andy Lee wrote:
If you look at the rest of my original suggestion (before the
clarification above), I suggested the term Nib's Loader as a
replacement for File's Owner, which would connote something
behavioral
As one who has been on the Cocoa road slowly over the last year (not
much in the middle, though), it has let me learn and absorb Cocoa
terminology and ideas slowly. But the one thing I found weird was
File's Owner. I knew what it meant. I knew what it does (and
especially after this past
owner in You've Got Mail), so that's one way you might conceptualize the
generality of File's Owner.
___
Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)
Please do not post admin requests or moderator comments to the list.
Contact the moderators
while the discussion of possible re-positioning of the term file's
owner is interesting, discussing it here isn't going to change how it
is referred to in the documentation (and for that matter, I doubt it'd
be changed from file's owner anyways...)
please take it off-list
thanks
scott
Look at the other Currency Converter example (the non bindings one)
http://developer.apple.com/documentation/Cocoa/Conceptual/ObjCTutorial/01Introduction/chapter_1_section_1.html
this uses almost the exact same structure you're looking to implement.
On May 25, 2008, at 5:01 AM, Roland King
.
That is exactly how mine are set up - connected to the Controller
Object. The tutorial says nothing about File's Owner.
And, if I don't understand something, I will ask why. This is not
magic - there is actual computer code behind that File's Owner
concept, and it is deterministic, not vague
the controller in the nib. Have the
controller be the File's Owner. So, the controller is created in code
in response to some action or notification or delegate method (e.g.
applicationWillFinishLaunching:). Then the nib is loaded, and the
controller is passed in as its owner. In the nib
that File's
Owner concept, and it is deterministic, not vague, not abstract, not
a philosophical enigma, not random, not ambiguous. If I had the
source code I could see what it does.
But that's where you're leading yourself astray -- there isn't any
source code to see. The nib file
way, run it --
i.e., post our new, improved explanation -- and find it still fails. [1]
I submit that instead of recoding the explain File's Owner
algorithm, other approaches might lead to a quicker resolution.
One alternative is a printf approach to narrowing down the problem.
Just as we
On May 25, 2008, at 6:31 AM, Andy Lee wrote:
The File's Owner is the hole -- the one thing that *isn't* created
in the nib.
First Responder and Application are also not created in the nib. :)
Indeed, that's why I didn't sleep so well -- something was nagging as
I clicked Send just before
On May 25, 2008, at 9:13 AM, Johnny Lundy wrote:
Took about a month of 16-hour days to get that down.
Experience suggests that this is a suboptimal way to try to learn Cocoa.
Some concepts are better understood after quiet reflection.
If you're struggling with a concept, find something else
On Sun, May 25, 2008 at 2:31 PM, Andy Lee [EMAIL PROTECTED] wrote:
If I can make a rough analogy, many of our answers have been like different
re-implementations of an algorithm. Like the guy on the guillotine in that
engineer joke, we each think we see what the problem is. And so we recode
Thanks to everyone who replied and supplied sample code and anecdotes.
I will study these carefully and take notes.
N.B. My 16 hours a day comment did not imply that I am losing sleep. I
really have been reading and adding features to my project, and
creating dozens of test projects, and
On 25 May '08, at 11:58 AM, Hamish Allan wrote:
What this thread has reminded me of is an ongoing conversation I have
with a friend of mine, who refuses to countenance the square root of
minus one, because he doesn't think it means anything.
It also reminded me of the fact that Isaac Asimov
On May 25, 2008, at 1:30 PM, Andy Lee wrote:
Early in his book, Aaron Hillegass suggests ten hours of sleep a
night when you're learning something new
Given my commitment to lifelong learning, that is now my official
excuse for sleeping in late. :-)
sherm--
, you were a Ham
radio operator), you might have more difficulty learning some concepts
because you had preconceived ideas that were incorrect. (By the way,
electrical engineering is where you will use complex numbers.)
More to the subject at hand, I thought File's owner was just
On 24 May 2008, at 05:39, Andreas Mayer wrote:
I thought, maybe a picture would help:
http://www.harmless.de/images/other/files_owner.png
Exactly the picture I was about to draw.
Johnny Lundy wrote:
Saying it connects the nib to an object outside the nib sounds good,
but what object is
On Sat, May 24, 2008 at 6:49 AM, Paul Sargent [EMAIL PROTECTED] wrote:
On 24 May 2008, at 05:39, Andreas Mayer wrote:
I thought, maybe a picture would help:
http://www.harmless.de/images/other/files_owner.png
Exactly the picture I was about to draw.
Johnny Lundy wrote:
Saying it
I dunno. Your book seems to be one of the few, if not the only, that
is not on my bookshelf.
If you email me your page on File's Owner, I can give feedback.
On May 23, 2008, at 9:59 PM, [EMAIL PROTECTED] wrote:
I despair that I am unable to adequately explain the concept and
utility
I decided to once again go verbatim through Cocoa Fundamentals. So far
it has been largely uh-huh, yep, but the File's Owner, my nemesis,
comes up again.
http://developer.apple.com/documentation/Cocoa/Conceptual/CocoaFundamentals/CommunicatingWithObjects/chapter_6_section_3.html
You connect
I'm trying to figure out why the big hang up on needing to understand
it fully. Not understanding it should not prevent you from developing
applications. So why the hangup? What is the actual problem? Just set
your own NSObject based app delegate as the File's Owner delegate in
IB
On Fri, May 23, 2008 at 11:49 AM, Johnny Lundy [EMAIL PROTECTED] wrote:
I sent feedback on this as File's Owner is mentioned several times and not
defined. There seems to be some huge problem with File's Owner. Even Aaron
Hillegass says that people have trouble understanding File's Owner
On May 23, 2008, at 2:49 PM, Johnny Lundy wrote:
I decided to once again go verbatim through Cocoa Fundamentals. So
far it has been largely uh-huh, yep, but the File's Owner, my
nemesis, comes up again.
I tried to answer your File's Owner and NSApp questions last week
(copied below
app delegate as the File's
Owner delegate in IB and start adding your code to it. That's really
all you *need* to know.
-Matt
--
Matt Long
[EMAIL PROTECTED]
http://www.matthew-long.com/
On May 23, 2008, at 12:49 PM, Johnny Lundy [EMAIL PROTECTED]
wrote:
I decided
/documentation/Cocoa/Conceptual/CocoaFundamentals/CoreAppArchitecture/chapter_7_section_8.html
(the first hit on Google for cocoa file's owner):
You use the File's Owner object as the conduit for connections
between objects in the nib file and objects outside of it.
which then point to *Further
On May 23, 2008, at 5:30 PM, [EMAIL PROTECTED] wrote:
Message: 3
Date: Fri, 23 May 2008 16:55:13 -0400
From: Andy Lee [EMAIL PROTECTED]
Subject: Re: File's Owner
To: Cocoa-dev cocoa-dev@lists.apple.com
Message-ID: [EMAIL PROTECTED]
Content-Type: text/plain; charset=US-ASCII; format=flowed
John -
I'd like to be able to describe the concept of File's Owner and First
Responder to people clearly. I don't think I would have described it
any differently than Key Thomases did early today. I've copied his
explanation below.
Did you find Ken's explanation helpful?
Jon Hess
On May 23, 2008, at 5:30 PM, [EMAIL PROTECTED] wrote:
On May 23, 2008, at 2:49 PM, Johnny Lundy wrote:
I decided to once again go verbatim through Cocoa Fundamentals. So
far it has been largely uh-huh, yep, but the File's Owner, my
nemesis, comes up again.
[deleted]
Again, I'm sensing a very
. I need to find out what NSApp is doing to my
nib file objects to manage them.
I'm getting closer. Thanks for the reference.
On May 23, 2008, at 7:36 PM, Julien Jalon wrote:
File's Owner can be any object in your application but is most often
set to the controller object that manages
a controller to
File's Owner and it will see all the properties of all the objects
in the class that File's Owner is set to, that would be cool. In that
case it is just serving as an instance of a class and can be used to
reach properties of objects of that class.
Yes, exactly: it will see all
An example of multiple nibs where a nib's File's Owner wouldn't
necessarily be NSApp would be System Preferences and the
preferencepane bundles that it loads.
NSApp would be SystemPreferences.app, and owns the main nib of the
application.
Each preference pane is an instance
Hi all,
I have a nib file containing an NSObjectController. The
NSObjectController's content is set to the File's Owner proxy object,
and this creates a retain cycle. (The file's owner never gets
deallocated because the object controller retains it, and the object
controller never gets
On May 15, 2008, at 2:21 AM, André Pang wrote:
I have a nib file containing an NSObjectController. The
NSObjectController's content is set to the File's Owner proxy
object, and this creates a retain cycle. (The file's owner never
gets deallocated because the object controller retains
On 15/05/2008, at 5:21 PM, André Pang wrote:
I have a nib file containing an NSObjectController. The
NSObjectController's content is set to the File's Owner proxy
object, and this creates a retain cycle. (The file's owner never
gets deallocated because the object controller retains
On 15/05/2008, at 5:21 PM, André Pang wrote:
I have a nib file containing an NSObjectController. The
NSObjectController's content is set to the File's Owner proxy
object, and this creates a retain cycle. (The file's owner never
gets deallocated because the object controller retains
text field binding
that was bound through the object controller to an ivar in the
file's owner.
However, now the weird thing is that I call -[objectController
release] in the file's owner -dealloc (which I guess should be the
correct behaviour, since the object controller is declared
I'm trying to set the action for an NSSlider in a little helper class
that is not the file's owner class associated with the window in the
nib. At runtime, I get these console messages:
*** +[SliderHelper myAction:]: unrecognized selector sent to class
0xeb74380
HIToolbox: ignoring
On Thu, May 15, 2008 at 10:12 PM, Rua Haszard Morris
[EMAIL PROTECTED] wrote:
I'm trying to set the action for an NSSlider in a little helper class that
is not the file's owner class associated with the window in the nib. At
runtime, I get these console messages:
*** +[SliderHelper myAction
98 matches
Mail list logo
