| Actually, I went and did the test, and there is something that bothers me. Let's say I have the same textfield as before, that binds to a default value via a NSUderDefaultControler. The defaults are registered (also as initial values), and the right value is shown in my window.
But, when I select the content of the NSTextFieldView and erase it (hit backspace), the field remains empty (the NSTextFieldView), but on the model side, the right (registered default) value is set, but the textfield never shows that visually. I had to resort to setting a Null Placeholder in the bindings, but it doesn't feel right to me. It breaks the automatism behind NSUserDefaults and its controler. For example, when I want to modify the defaults for this value (between released versions for example), I also need to edit the null placeholder in IB. I feel it should always fallback to the defaults or the initial value instead of setting the value to nil...
Should I consider this as a cocoa bug and file it ?
(All this is inside my prefs window. Closing then re-opening the window doesn't update the value...)
thanks On May 18, 2005, at 4:02 PM, Scott Anguish wrote: it depends on your application, but just relying on the registered defaults should be fine
On May 18, 2005, at 5:25 AM, Nicolas Berloquin wrote: I have a related question about bindings and user defaults. I use bindings for my prefs window that bind to NSUserDefaults that are registered in my NSApplication (with registerDefaults: ). For example, let's say that one of the values is a number that is shown in an editable NSTextField. My question is : In IB, in the bindings pane, should I set a value for 'Null Placeholder', and should I enter a value in the control also ? Or should I completely rely on the registered defaults ?
|