The 'Value' Binding for NSTextView
I just got a question about Core Data, and the answer is obscure enough that I think it's worth mentioning here.I have a question concerning the binding of the 'body' attribute of the Post entity to NSTextView.
After going through your tutorial I tried to use Core Data for an app and it works great, except for the fact that in my MainMenu.nib file I get a "data" binding option for NSTextView instead of the "value" binding in BlogDemo.
Binding the body attribute to the "data" option gives me an error at runtime because it cannot convert to NSData from a "string of class NSCFString".
I can't find any difference between your project and mine, except a slightly different layout.
(edited for clarity/length)
I turns out the difference is one tiny checkbox in the Attributes pane of Interface Builder's inspector window.
All you have to do is select the NSTextView (may be necessary to double-click since it's embedded in a scroll view), then deactivate the checkbox that reads "Allows user to change fonts."
The reason for all of this is rich text is stored as an NSData object, so you have to disable fonts to store the text view's contents as an NSString.
So why not just use data for the type instead? NSPredicates can't find text in data attributes, so it's a lot less convenient for things like fetched properties and filtered searches. In most cases, they way around this is to have two representations of the same data: one for display and one for searching.
The 'Value' Binding for NSTextView
Posted May 30, 2005 — 2 comments below
Posted May 30, 2005 — 2 comments below
Flofl — Aug 09, 05 334
Scott Stevenson — Aug 09, 05 335
I certainly understand the idea of it being inconvenient, but keep in mind that the idea is to make Core Data function the same across any type of store. Text searching in binary data may not work the same in all file formats. Not necessarily impossible, though.