Re: Core Data issue .. where is my bug?
Le 14 juin 2010 à 07:32, Robert Lorentz a écrit : > Now - this is where my issue starts - if I instead bind my NSTextField to > "array controller - selection.description", my program crashes with EXC BAD > ACCESS! I have edited the store file, and confirmed that yes I do have > attribute entries for "name" and "description" both. Description is a kind of reserved name: it is normally bound in every object (since it is defined in the NSObject root class) to a method giving the result of "print operation" like NSLog(@"%@", object). Try to use another name instead, like "descr", for example. Vincent___ 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
Core Data issue .. where is my bug?
Ok I have a core data .xcdatamodel created, and I've trimmed it down to include: Entity: MyType has attributes: name (string), description (string) - both have default values, both not-optional. I have set up an NSTableView with + and - buttons to add or remove MyType to an NSArrayController I call "array controller". The table view is set up to display "name". This works, I can add and remove names all day long, edit their values, etc. My bindings all appear to be good there. (I'm binding Content and I'm binding Value) I have also bound "selectionIndexes" from the tableview to the array controller's 'selectionIndexes'. I have created a NSTextField. In the text field, I can set it's value to "array controller - selection.name" .. if I do this, the text field shows the same data as the name row that I click on in my NSTableView. If I edit it in either place, it updates. Now - this is where my issue starts - if I instead bind my NSTextField to "array controller - selection.description", my program crashes with EXC BAD ACCESS! I have edited the store file, and confirmed that yes I do have attribute entries for "name" and "description" both. My bindings of selectionIndexes and selection are intended to say: when you click the name of this MyType, really I am selecting the index of the MyType entity in the array controller (since the array controller is set up to manage entities of type MyType..) So, when I then go to array controller and bind to "selection.description" I see no reason why it wouldn't return back the right data. 4Default MyType Description Any help is appreciated as I've fooled with this for quite a while now. I'm also very unclear as to how to constructively debug this sort of thing, I don't know the tools well but it all seems very "behind the scenes"... so tips as to how to debug it better appreciated.___ 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
Re: Menu item binding hidden
Ok thanks Kyle and Gideon, I wanted to make sure there wasn't another way with a binding that I was over looking. -Tony On Jun 13, 2010, at 7:21 PM, Gideon King wrote: > You might like to check out doing it using validateUserInterfaceItem: or > validateMenuItem: > > HTH > > Gideon > > On 14/06/2010, at 11:23 AM, Tony Romano wrote: > >> Binding a menuitem's hidden attribute to the selection doesn't work in the >> case of a context menu because the selection happens as it changes and >> before the menu is displayed. There is no state. Other than adding an ivar >> and binding the hidden state to it, is there another way? Can't seem to >> find anything via a search. >> >> TIA, >> -Tony >> > > -Tony ___ 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
Re: Menu item binding hidden
You might like to check out doing it using validateUserInterfaceItem: or validateMenuItem: HTH Gideon On 14/06/2010, at 11:23 AM, Tony Romano wrote: > Binding a menuitem's hidden attribute to the selection doesn't work in the > case of a context menu because the selection happens as it changes and before > the menu is displayed. There is no state. Other than adding an ivar and > binding the hidden state to it, is there another way? Can't seem to find > anything via a search. > > TIA, > -Tony > ___ 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
Re: Menu item binding hidden
On Sun, Jun 13, 2010 at 6:23 PM, Tony Romano wrote: > Binding a menuitem's hidden attribute to the selection doesn't work in the > case of a context menu because the selection happens as it changes and before > the menu is displayed. There is no state. Other than adding an ivar and > binding the hidden state to it, is there another way? Can't seem to find > anything via a search. Regular old menu validation? --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 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
Menu item binding hidden
Binding a menuitem's hidden attribute to the selection doesn't work in the case of a context menu because the selection happens as it changes and before the menu is displayed. There is no state. Other than adding an ivar and binding the hidden state to it, is there another way? Can't seem to find anything via a search. TIA, -Tony ___ 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
Re: How to debug invalidated core data object
Thanks Jerry > > Whoops/sorry. I forgot that -[NSManagedObject valueForKey:] is an Apple > method so all you get is stupid registers and no symbols. (Text is not > colorized in email.) > > So there are two ways to do this. One way would be, assuming that all of > your managed objects descend from some subclass of NSManagedObject which you > have defined, override -valueForKey: and NSLog in there. Mercifully, > -valueForKey: is *not* listed in "Methods you Must Not Override" or "Methods > you Are Discouraged From Overriding", so it might work. You may be able to > reduce the fire-hose of log messages by conditioning it with if ([self > isFault]). But maybe you can stand the fire-hose because it's just the last > one before the exception that you're interested in. Too bad we don't have > -isInvalidated. The other way is to do same logging in a Method Replacement > of -valueForKey:. > > You see why I try and go top-down. Good idea - yes I do already have a subclass of NSManagedObject that my objects all inherit from, so that would be easy to implement. It's still looking at the symptoms rather than the causes though, so I'll work my way through the other things as the core attack, but put this logging in there too so I can see what's being triggered - should help speed up the process... > >> I sort of stumble across some registers that have some interesting data in >> them. I've tried to look at the GDB and Apple documentation (Debugging with >> GDB, Getting started with GDB), but it all seems to assume that you already >> know which registers are what, and how to find what you are looking for once >> you are at a particular frame. Are there any resources that would fill in >> this missing information for me so that I can debug more effectively? > > After spending several hours reading about it one day I concluded that, > because of all the indirection in Objective C, looking at registers and > picking out method parameters, etc. is more much more complicated than rocket > science. If anyone can explain a procedure for doing such, it would be a > real "contribution to the community" :) > So glad to hear that this is not just me being thick ;-) ___ 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
Re: How to debug invalidated core data object
On 2010 Jun 13, at 17:34, Gideon King wrote: > From the top down approach, the places I could envisage this problem > originating are: > 1. NSNotificationQueue - queued notifications that get fired after I have > released the MOC, and the objects have been faulted and invalidated but not > removed yet. The problem here is the queue opacity. I would really like to be > able to stop at my release of the MOC and look at what was queued at the > time, and when I dequeue notifications, I would like to see whether the > matching had actually removed the required notifications. > 2. Anything that is performed using the afterDelay option. Again, the opacity > of the event queue means that I don't know of a way of peeking into the event > queue and seeing what is pending. > 3. Anything that is using these type of facilities behind the scenes, and in > this case I am thinking in particular of the drawing system where it will > fire off the display message on the next run loop to coalesce the dirty rects > etc. The drawing code in my application does make many calls into the > underlying core data objects to tell what to draw. That looks good to me :( > Wading through all of this top down is going to be very time consuming, but > if necessary, then I guess that's just what I'll have to do - peel it away > bit by bit. > > I'm not sure exactly how to get the value of "self" on a particular stack > frame - I click on a frame, and use "info registers", I can try to "po" all > the addresses that I see, but I don't really know what I am seeing. Whoops/sorry. I forgot that -[NSManagedObject valueForKey:] is an Apple method so all you get is stupid registers and no symbols. (Text is not colorized in email.) So there are two ways to do this. One way would be, assuming that all of your managed objects descend from some subclass of NSManagedObject which you have defined, override -valueForKey: and NSLog in there. Mercifully, -valueForKey: is *not* listed in "Methods you Must Not Override" or "Methods you Are Discouraged From Overriding", so it might work. You may be able to reduce the fire-hose of log messages by conditioning it with if ([self isFault]). But maybe you can stand the fire-hose because it's just the last one before the exception that you're interested in. Too bad we don't have -isInvalidated. The other way is to do same logging in a Method Replacement of -valueForKey:. You see why I try and go top-down. > I sort of stumble across some registers that have some interesting data in > them. I've tried to look at the GDB and Apple documentation (Debugging with > GDB, Getting started with GDB), but it all seems to assume that you already > know which registers are what, and how to find what you are looking for once > you are at a particular frame. Are there any resources that would fill in > this missing information for me so that I can debug more effectively? After spending several hours reading about it one day I concluded that, because of all the indirection in Objective C, looking at registers and picking out method parameters, etc. is more much more complicated than rocket science. If anyone can explain a procedure for doing such, it would be a real "contribution to the community" :) ___ 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
Re: How to debug invalidated core data object
Thanks Jerry & mm @mm The problem is I don't know what to put breakpoints on @jerry My understanding is that with the core data, they have their own memory management scheme which will reuse the space of something that has been invalidated, and that invalidated is not equal to deallocated. If I examine the registers and print out the values of each, I can see the managed object at $rax - this is the exception description, and if I po [$rax userInfo], it is nil. I can see the name of the key it is trying to look up in $r14, but although this is useful information and helps me identify both the entity and the key, it really doesn't help me to narrow it down any closer than maybe 40,000 lines of code, because I believe the actual key just happens to be the one it hits first, and the real issue is why there is a key lookup happening at all. All the objects should be gone and all observers deregistered, all messages canceled etc. The code hasn't been exercised in this way before, so the issue has probably been there forever, so looking at recent changes isn't going to help. Half the code in question was written by someone who is no longer around, and although I have gone through it and found *many* issues, which I have corrected, I am still concerned that there may be something hidden in there that I am not aware of. Before posting to this list, I did manage to get through a couple of layers of invalidated object messages by finding queued notifications and dequeueing them, but seeing as the NSNotificationQueue is completely opaque as far as I can tell, I can't see whether the notification removal was effective at matching what was in the queue. From the top down approach, the places I could envisage this problem originating are: 1. NSNotificationQueue - queued notifications that get fired after I have released the MOC, and the objects have been faulted and invalidated but not removed yet. The problem here is the queue opacity. I would really like to be able to stop at my release of the MOC and look at what was queued at the time, and when I dequeue notifications, I would like to see whether the matching had actually removed the required notifications. 2. Anything that is performed using the afterDelay option. Again, the opacity of the event queue means that I don't know of a way of peeking into the event queue and seeing what is pending. 3. Anything that is using these type of facilities behind the scenes, and in this case I am thinking in particular of the drawing system where it will fire off the display message on the next run loop to coalesce the dirty rects etc. The drawing code in my application does make many calls into the underlying core data objects to tell what to draw. Wading through all of this top down is going to be very time consuming, but if necessary, then I guess that's just what I'll have to do - peel it away bit by bit. I'm not sure exactly how to get the value of "self" on a particular stack frame - I click on a frame, and use "info registers", I can try to "po" all the addresses that I see, but I don't really know what I am seeing. I sort of stumble across some registers that have some interesting data in them. I've tried to look at the GDB and Apple documentation (Debugging with GDB, Getting started with GDB), but it all seems to assume that you already know which registers are what, and how to find what you are looking for once you are at a particular frame. Are there any resources that would fill in this missing information for me so that I can debug more effectively? So say I clicked on a frame, and the assembly showed: 0x7fff84b6c0c6 <+0723> lea-0x1427b72d(%rip),%rsi# 0x7fff708f09a0 I understand that the first couple of things are some sort of frame pointer and offset, but don't really know whether they are of any practical use to me in debugging, and the rest of it, I don't understand the assembly or the comment, but I would like to know how I can get from there to accessing the target (self) and the args to the method. Thanks Gideon On 14/06/2010, at 8:43 AM, Jerry Krinock wrote: > >> #5 0x7fff83bf74be in -[NSManagedObject valueForKey:] () > > get the value of self, and then send some messages to it in the debugger > console. For example, if self is 0xabcdabcdabcdabcd, > > po 0xabcdabcdabcdabcd > po [0xabcdabcdabcdabcd entity] > ___ 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
Re: How to debug invalidated core data object
On 2010 Jun 13, at 08:49, Gideon King wrote: > I get an exception ... The NSManagedObject with ID:(whatever) has been > invalidated. Those things always ruin my day. I don't think I've ever fixed one by debugging from the bottom up as you would like to do. The solution has always come from thinking back and review everything I'd changed recently. > I'd really appreciate any suggestions about how to pinpoint the source of > this problem. I wonder if by "invalidated" they mean "deallocated"? If not, you could click on this call: > #5 0x7fff83bf74be in -[NSManagedObject valueForKey:] () get the value of self, and then send some messages to it in the debugger console. For example, if self is 0xabcdabcdabcdabcd, po 0xabcdabcdabcdabcd po [0xabcdabcdabcdabcd entity] ___ 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
SOLVED: Process executes an AppleScript, then disappears.
On 2010 Jun 13, at 12:34, Dave Keck wrote:
>> What might cause this process to exit? Where can I look for clues? (I've
>> been guessing for two hours, so any suggestion will be welcome.) Does the
>> system log the exit states of processes anywhere?
>
> I would attach to the process while it's executing (in Xcode, Run >
> Attach to Process) and set a breakpoint on exit()/_exit() to get a
> backtrace when it exits.
Thanks, Dave. That gave me the clue I needed.
Although no break occurred on either symbol 'exit' nor '_exit', gdb noted that
"Program received signal SIGTERM". So I ran a little DTrace probe [1] process
to see who was sending SIGTERM, and the answer was that it was sending SIGTERM
to itself, which didn't make any sense, but got me to thinking and then I
discovered the real problem which was that the app which was running the
AppleScript concludes with a wholesale unloading, rewriting and reloading of
all its launchd configurations, including the one which had launched the tool.
And according to man launchctl, unloading a configuration kills any of its
processes which happen to be still running.
Oh well, not be a Cocoa problem. Need to be more selective in my launchd
housekeeping.
[1]
#!/usr/sbin/dtrace -qs
proc:::signal-send
/args[2] == SIGTERM/
{
printf("SIGTERM was sent by %s pid=%d \n", \
args[1]->pr_fname,args[1]->pr_pid);
}
# This script was adapted from
http://www.sun.com/bigadmin/features/articles/dtrace_truss.jsp
___
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
Re: Process executes an AppleScript, then disappears. Why/How?
> What might cause this process to exit? Where can I look for clues? (I've > been guessing for two hours, so any suggestion will be welcome.) Does the > system log the exit states of processes anywhere? I would attach to the process while it's executing (in Xcode, Run > Attach to Process) and set a breakpoint on exit()/_exit() to get a backtrace when it exits. ___ 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
Process executes an AppleScript, then disappears. Why/How?
A short-lived "worker" tool is launched by launchd, triggered by a launchd
"WatchPath". After determining what needs to be done, this tool executes an
NSAppleScript which tells a running application process to do some work. The
app does its work, which takes about 15 seconds.
Expected Result: Tool should continue execution with next line of code.
Actual Result: Tool's pid disappears from Activity Monitor immediately after
the app completes is script, and no more code is executed.
There is no runLoop in this tool; it simply executes main() from top to bottom.
In the launchd plist, I've set the TimeOut and ExitTimeOut keys to integers of
60 seconds, more than enough time for the NSAppleScript to complete. Here is
the relevant code in the tool:
NSLog(@"Will execute script") ;
id shouldBeNil = [script executeAndReturnError:&errorInfo] ;
NSLog(@"script return = %@", shouldBeNil) ;
NSLog(@"script error = %@", errorInfo) ;
printf("Did execute script, C print\n") ;
NSLog(@"Did execute script") ;
NSBeep() ;
sleep(10) ;
The console log says "Will execute script", but no more. No NSBeep() either.
What might cause this process to exit? Where can I look for clues? (I've been
guessing for two hours, so any suggestion will be welcome.) Does the system
log the exit states of processes anywhere?
Thank you,
Jerry Krinock
___
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
How to debug invalidated core data object
I have a situation where I create a temporary managed object context and do a bunch of things with various managed objects before releasing the context again. After this, there appears to be an asynchronous cleanup operation done by coredata, at which point I get an exception as per the trace below (The NSManagedObject with ID:(whatever) has been invalidated). I'm sure that there is something somewhere in my code where I am either setting up a queued notification or something like that which is being called after the context has been released, or something being picked up in the drawing code etc, but there are many thousands of lines of code, all sorts of windows and views involved, so it looks really hard to narrow it down. I'd really appreciate any suggestions about how to pinpoint the source of this problem. #0 0x7fff832070da in objc_exception_throw () #1 0x7fff83c4b11a in -[_NSInvalidationFaultHandler fulfillFault:withContext:] () #2 0x7fff83beddbe in _PF_FulfillDeferredFault () #3 0x7fff83bf1ab7 in _sharedIMPL_pvfk_core () #4 0x7fff83bf1c28 in -[NSManagedObject(_PFDynamicAccessorsAndPropertySupport) _genericValueForKey:withIndex:flags:] () #5 0x7fff83bf74be in -[NSManagedObject valueForKey:] () #6 0x7fff84a95d34 in -[NSObject(NSKeyValueCoding) valueForKeyPath:] () #7 0x7fff84a95dca in -[NSObject(NSKeyValueCoding) valueForKeyPath:] () #8 0x7fff84a99843 in NSKeyValueWillChangeBySetting () #9 0x7fff84a9921c in NSKeyValueWillChange () #10 0x7fff84b6c0c6 in -[NSObject(NSKeyValueObservingPrivate) _willChangeValuesForKeys:] () #11 0x7fff83bf8c60 in -[NSFaultHandler turnObject:intoFaultWithContext:] () #12 0x7fff83c0a254 in -[NSManagedObjectContext(_NSInternalAdditions) _disposeObjects:count:notifyParent:] () #13 0x7fff83c09b48 in -[NSManagedObjectContext(_NSInternalAdditions) _dispose:] () #14 0x7fff83c2fc69 in _deallocateContextBackgroundThread () #15 0x7fff83bcbe10 in minion_duties2 () #16 0x7fff8385a8b6 in _pthread_start () #17 0x7fff8385a769 in thread_start () Thanks Gideon ___ 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
Re: NSArrayController/Modal dialog/KVO Gordian knot
Hallo Reinhard, Le 13 juin 2010 à 09:36, Reinhard Segeler a écrit : > I am not familiar with the NSDictionaryController but the keypath looks a bit > strange: > > if theDictionary is what the name says, then a member selection calls a > member value calls a member color. That's not the case, isn't it? theDictionary has a selection made of key/value couples ; each couple is a KVO-compliant object for the keys "key" and "value" and the value is a class object which features a + (NSString *)color method. Believe me, it works all right. > In my code I bind a popupMenu by using the following path: self.dict.index to > select a menu item by index. - no Controller is used here. > > I looked in my literature where I found the following: > > Bind to: aDictController > Controller key: selection > Model key path: name -> in your case color? In your case, you forget a step (choose between "key" and "value" attributes). Actually, I found a solution to my problem. Instead of observing the "contents" property of the array to catch changes in the dictionary, I observe "selection" and that works. It does not explain why the "contents" observation does not trigger messaging while the dialog is active, albeit I insert an object in the array. Tchüß, Vincent___ 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
Re: applicationShouldTerminate gets called on with no edited documents
Am 11.06.2010 um 23:51 schrieb Brad Stone: If applicationShouldTerminate would get called like it does with no edited documents I would be in great shape. Why doesn't applicationShouldTerminate get called? ___ 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
Re: NSArrayController/Modal dialog/KVO Gordian knot
-- Reinhard Am 12.06.2010 um 17:30 schrieb vincent habchi: the color field should be set to : theDictionary.selection.value.color; I am not familiar with the NSDictionaryController but the keypath looks a bit strange: if theDictionary is what the name says, then a member selection calls a member value calls a member color. That's not the case, isn't it? In my code I bind a popupMenu by using the following path: self.dict.index to select a menu item by index. - no Controller is used here. I looked in my literature where I found the following: Bind to: aDictController Controller key: selection Model key path: name -> in your case color? Depending on your idea, I think that the "fruitName" key or value of the fruitDictController must be connected to the key "fruitName" of the colorDictController to get the desired color. ___ 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
Re: userDefaultsDidChange is causing a loop with dependent checkbox values
How do you bind them to your checkbox? Do other checkboxes change the NSUserdefaults also, when one setting changes, then this can cause the loop, depending hwo they influence each other! When binding values with defaults - or other settings - you don't need NSUserDefaultsDidChangeNotification or userDefaultsDidChange(), because the binding updates the values for you. It maybe that the value currently used is not registered in the NSUserdefaults database. But I think, that with bindings this problem should not occur. -- Reinhard Am 12.06.2010 um 20:25 schrieb Adam Gerson: I have set up some NSUserDefaults and used bindings to bind them to some checkboxes and radiobuttons in my nib. I want the act of checking some of the checkboxes to uncheck or check other checkboxes. I did this by registering for a NSUserDefaultsDidChangeNotification. Then inside userDefaultsDidChange() I have some if statements that check the current value of checkbox A and set checkbox B to what I want it to be. However the problem I am having is that [checkboxB setState:0] only changes the value on the screen but does not update the defaults saved value in the file and changing the default directly with [defaults setBool:NO forKey:@"checkboxB"] causes a loop by calling userDefaultsDidChange() again. This must cause a loop, if [defaults setBool: ...] is set in the userDefaultsDidChange() method, because you change a defaults value and want to be informed about that, isn't it? What is the right way to achieve this kind of one checkbox dependent on anothers value with NSUserDefaults and bindings? I am using settings from defaults and in other ways, bound them in combination with NSValueTransformer, that works nice, for the display on screen, but could be used also to change defaults. But the trick is not the binding alone, it seems, that your combination of settings is the problem: CheckboxA changes CheckboxB changes CheckboxD changes CheckboxA... Thanks, Adam ___ 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/macmeideln%40googlemail.com This email sent to macmeid...@googlemail.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
