Hi,
actually, I used the binding to the "Content" fields of NSPopUpButton
because the possible selection that has to be displayed in the PopUp
changes dynamically. Otherwise I could just have set the menu in IB.
I put a breakpoint on controlTypes and it does return an NSArray
filled with NSCFStrings. But none of them are displayed in the menu.
The function is called everytime when it is supposed to be called,
i.e. everytime the menu changes. I never call that function myself.
The strange thing is, this worked beautifully under Leopard....
Any clues?
On 14.09.2009, at 23:33, Quincey Morris wrote:
On Sep 14, 2009, at 14:07, ALEXander wrote:
What do you mean by KVO compliant? I already have added a
setControlTypes function, this was not necessary in Leopard and also
does not fix the bug in Snow Leopard.
On Sep 13, 2009, at 15:11, ALEXander wrote:
1) in the File's Owner class I defined a function returning an
NSArray:
- (NSArray*) controlTypes
{
if ([[self selectedControls] count]) {
NSArray *returnArray = [NSArray arrayWithArray:[[[[self
selectedControls] objectAtIndex:0] configTypes] allKeys]];
return returnArray;
} else {
return nil;
}
}
The value returned by controlTypes looks like an array of dictionary
keys (configTypes allKeys), where the dictionary itself comes from
an array (selectedControls objectAtIndex:).
So the value returned by controlTypes *depends* on the values of
other objects, which may themselves depend on the contents of the
NIB being loaded.
But 'controlTypes' may be getting called before those other objects
are being loaded. If '[self selectedControls]' returns nil at the
time 'controlTypes' is called, for example, then 'controlTypes' will
return an empty array.
KVO compliance, in this case, means that if the value of 'self
selectedControls' or 'configTypes allKeys' changes later in the NIB
loading process, then 'controlTypes' needs to be called again by the
user interface, to get its new (correct) value.
In a case like this, you might be able to get compliance by making
'controlTypes' dependent on other keys (in Leopard, implement
+keyPathsForValuesAffectingControlTypes) or by manually calling
willChange/didChangeValueForKey: @"controlTypes" when the underlying
objects change.
Of course, if the value of 'controlTypes' is available before NIB
loading starts and never changes, this is all irrelevant and the
problem is somewhere else.
You could try setting a breakpoint in 'controlTypes' and see:
a. Is NIB loading in progress?
b. Does it maybe return an empty array the first time? Maybe it only
returns the correct array later, when it's too late.
_______________________________________________
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/alexander%40wackazong.com
This email sent to alexan...@wackazong.com
_______________________________________________
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
