• Open Menu Close Menu
  • Apple
  • Shopping Bag
  • Apple
  • Mac
  • iPad
  • iPhone
  • Watch
  • TV
  • Music
  • Support
  • Search apple.com
  • Shopping Bag

Lists

Open Menu Close Menu
  • Terms and Conditions
  • Lists hosted on this site
  • Email the Postmaster
  • Tips for posting to public mailing lists
Re: Cocoa Binding Musings
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Cocoa Binding Musings


  • Subject: Re: Cocoa Binding Musings
  • From: Scott Anguish <email@hidden>
  • Date: Mon, 10 May 2004 16:37:29 -0400

On May 10, 2004, at 2:11 PM, Craig Hockenberry wrote:

I should begin by stating that the new Cocoa Binding technology is truly
amazing -- it's cut my development time considerably. To all those involved,
thank you!

Now, what follows are various things that I still don't understand or had
problems understanding in the month or two that I've been working with
bindings. Searches of the Apple list archives haven't proved useful, so if
these topics have been covered previously, please blame it on Mamasam.com
being down and out...

1) How does one localize the placeholder text in the value binding? My first
guess of it being a key for an entry in Localizable.strings proved wrong. It
seems unlikely that a German user will want to see "Please enter text" for a
null placeholder.

you'd locate it the same what you locate the UI, replace it in the German.nib.

2) I can't figure out how to remove a key from a NSUserDefaultsController.
For example:

id values = [[NSUserDefaultsController sharedUserDefaultsController]
values];
[values setValue:nil forKey:@"whatever"];

won't work on a text field or anything else that relies on NSString. Using
removeObjectForKey: or setNilValueForKey: don't work either.
revertToInitialValues: is too broad in scope.

In all my years as a developer of Cocoa/OpenStep apps, I don't think I've encountered a situation where I've needed to delete a default key.

but, you can do it in this case by getting the userDefaults

[[NSUserDefaultsController sharedUserDefaultsController] userDefaults];

and then use the -removeObjectForKey: method on that.

Likewise, it may be possible to just removeObjectForKey: on the object returned by -values (that I'm less sure of, since I don't believe there is any guarantee that it is a dictionary that you are dealing with there)



A similar problem exists for controls bound to NSData (and archived NSImage,
for example.)

Basically, how does one "reset" a control that has no initial value?

can you not just set it to nil?


3) It took me forever to figure out what the default value transformers
"NSIsNil", "NSIsNotNil", etc. did. Searching the Reference Library & Google
turned up nothing. By chance, I stumbled upon "NSIsNilTransformName" the
other day and it answered my question. Why does the documentation not match
IB?

IB is using the name of the transformer, whereas the doc uses the name of the Constant to refer to it.

All the supplied value transformers are documented in the value transformer topic.

http://developer.apple.com/documentation/Cocoa/Conceptual/ ValueTransformers/index.html


Why doesn't a search on developer.apple.com not match the "NSIsNil"
pattern?

I believe the default search is for the entire word. I'd be surprised if there isn't some way to do a more general search in the advanced search, and any Google options should work for it.


4) If File's Owner in IB is set to NSApplication, and the delegate is
connected to a class that supports KVC, the delegate never gets passed
get/set invocations. Obviously, you can work around this by creating a
separate NIB with File's Owner set to your class (alleviating the need to
have a delegate), but it's a pain for small applications. It seems like the
delegate should be able to handle the KVC on behalf of NSApplication. Am I
missing something, or is this a bug?

I'm not sure that I'd call this a bug, but perhaps an opportunity for enhancement. File it.

The best solution of course would be for IB to allow you to use more than just File's Owner and a few other IB items as model objects.


5) Text fields only update user defaults after the user has pressed the
enter key. (It's possible that this is true for other controls -- I think
I've seen this behavior in table cells.)

This seems like a bug from a HIG point-of-view -- if a user types "abc" into
a text field and then closes the application, the fact that they typed "abc"
is never recorded in the user defaults. Of course, you can track
controlTextDidChange: and update the model yourself, but that seems like a
lot of work for something I feel should be the standard behavior.

You can turn on "Updates Continuously" for an individual binding in IB.


6) Shouldn't there be an easy way to get a case insensitive sort from IB. I
realize that you can set up sort descriptors to get caseInsensitiveCompare:
instead of compare: -- but since views of the filesystem are common, it
would be nice to have some easy way to configure this directly in the NIB.

Agreed. Please file another bug. :-)


7) I have yet to find an easy way (e.g. no code) to "reset" a value which is
bound to another control. It would be VERY nice to have a capability where
pressing a button would cause a slider to go to a specified value (think
reset.) Or where some user action filled in a form with preset values. Or...

Being able to write as well as read (in the context of Interface Builder)
could be very powerful.


set the target/action of the button to a method that stocks the default/reset values in the model object. You can do this with the target/action bindings as well.


In closing, these are all fairly minor things (or feature requests.) The
only bad thing I can say about Cocoa Bindings is that it takes quite awhile
to wrap your head around it.

Yes, it can. It's something that we're working on making the documentation stronger on in an ongoing manner.

I had the very same issues just before WWDC last year. The difference was we had no documentation on it at the time, and only a small group of internal people know how to work with it. And to watch them do things was even more confusing because they had too much knowledge of how it worked, having actually created it.

Once you get it, there are only a few additional aspects that are still challenging to grasp. Ask here if you get stuck. I read the list religiously  and by that I mean while wearing a cassock  and help when I can. Also, questions asked here _do_ help form what is covered in future documentation. If it's obvious that something is causing people trouble, we can improve that specifically. I think this may have been evident in the latest update to the Controller docs.

And Craig, if you're still having trouble in July, I'll stop by when I'm in GSO. :-)

The fact that it's quick to get started was
very helpful and made me see benefits almost immediately. This list is
essentially my "where I've hit the wall" in the past couple of months of
heavy usage -- not bad at all for a new technology!


It's truly an amazing technology the bindings stuff. And it's only going to get better!
_______________________________________________
cocoa-dev mailing list | email@hidden
Help/Unsubscribe/Archives: http://www.lists.apple.com/mailman/listinfo/cocoa-dev
Do not post admin requests to the list. They will be ignored.


References: 
 >Cocoa Binding Musings (From: Craig Hockenberry <email@hidden>)

  • Prev by Date: Re: Callbacks, GUI updates and threading
  • Next by Date: Re: Re: Handling Undo/Redo in KVC To-Many Accessors
  • Previous by thread: Re: Cocoa Binding Musings
  • Next by thread: Resizing an NSTextField "on the fly"
  • Index(es):
    • Date
    • Thread