Retaining values of Text Views???

hey guys,

another question on the way…

i figured out, thanks to jay, how to retain values of text fields. now, i have tried the same process on a text view but it aint working. any ideas why?

this is what i did (which i adapted from the text fields method of retaining values):

first. open IB 3.0 and select the scroll view which contains the text view. then selected the text view and went to blindings. i ticked to blind it to “Data” (not value as in text fields as it not exists). then i gave it the model key path of “mkp_tv_snippets” i also tick “validates right away”

then i added this script:


on will finish launching theObject
	tell user defaults
...
		make new default entry at end of default entries with properties {name:"mkp_tv_snippets", content:""}
...
	end tell
	call method "synchronize" of object user defaults
	
end will finish launching

on should close theObject
	tell window "window" to set first responder to button "b_create"
	call method "synchronize" of object user defaults
end should close



dunno work :frowning: CRY. if i build the proj, i get an error of “AppleScript Error: -1708” when i launch the app

any ideas?

If you remove the binding, do you still get the error?

I didn’t have any problems in the example I just made. However, you will need to use the NSUnarchiveFromData value transformer for the text view data.

You should start by reading the bindings documentation, which clearly states that the data binding must point to rtf or rtfd data.

You can bind to the “value” binding but you have to enable it first. In the attributes pane for the text view in IB, make sure that the “Allows > Rich Text” checkbox is UNCHECKED. Once you uncheck the rich text option, the text view will only be configured to use a single font, which will expose the “value” binding of the text view in the bindings pane. You can then bind this to your user defaults key. Make sure you set the “Continuously Updates Value” checkbox so it registers the change with the defaults every time you make a change.

The whole point of bindings is to eliminate code. The code you posted that synchronizes the defaults and creates default entries is useless. Creating the key is handled automatically for you by the defaults system, and synchronization happens every time you make a change, thanks to the ‘continuously updates’ option I mentioned above.

See also

default entry

user-defaults

Bruce, perhaps instead…

Otherwise, you only need to create them yourself if you intend to access them manually using “user defaults” in your applescripts, and only if you intend to do so before you allow your text view to begin handling the binding on its own. If all your app does is hold static text in a view that doesn’t do anything else (like a note pad, perhaps) then you should never need to register your defaults. If your view keeps track of its content automatically using bindings, but then you also need to evaluate that text programmatically in your script, then you may or may not need to try to create the defaults before accessing them in your script. That’s something that would be dictated by the design of the controller and the interface. It’s also important to consider that accessing the data in the defaults may not be necessary if you’re using bindings to handle it’s persistence. Since the binding updates the defaults content automatically every time you make changes to the string in the view, it’s probably better (and safer) to access the content from the view rather than reading the data in the defaults. Whatever is in the view is visible to the user, and is typically better to work with because the user can verify that the text is what they want.

Typically text views display data in a “document-based” way, so binding to a value default is not really a common way to do things. In most cases, you’d bind to a controller key that would either manage a document or value dynamically in your code, allowing you access to multiple sources of data. Having the view bound to a single entity, while appropriate in the right circumstance, is kind of fringe for most applications. I guess it would be important to know exactly what guimkie is trying to accomplish to determine if using bindings is even necessary, whether there’s a better approach, whether there’s a need for programmatic user defaults access, and whether it’s ever necessary to create a default entry in your code. While it’s always best to code defensively to avoid errors, if all he’s doing is creating a ‘note pad’ then there’s no need to make a key manually, because bindings does NOT need to have them exist before trying to access them like user defaults does… it creates them quietly if it needs to.

Perhaps I should’ve added… Well, anything. I wasn’t saying that you’re wrong (I believe you knew that); I was just using the quote to segue into something else, which I didn’t describe.

Also, I agree with the rest of your reply.

hey you two,

sorry about not getting back earlier but i was busy.

i tried it without the rtf thing that jobu mentioned and it now works. i mixed it all together but now it works :smiley:

i guess i had the wrong blindings set.

thanks - great forum with great geniuses :smiley: