http://developer.apple.com/iphone/library/documentation/UIKit/Reference/UITextView_Class/Reference/UITextView.html#apple_ref/occ/instp/UITextView/text
Also see
http://www.geeksrus.com/2009/04/23/debugging-iphone-memory-releases
text
The text displayed by the text view.
@property(nonatomic, copy) NSString *text
This LIES!
First you think you are getting a copy of a NSString*, but you actually get an auto-released private subclass of NSString* which is a copy of the data.
Now if you execute this on the main thread via a NSInvocation, then what happens is the Squeak VM stops, and waits for
the NSInvocation to be executed on the main thread. The main thread run-loop logic creates an auto-release pool, then executes the invoke
which fetches the auto-released object from the UITextView and deposits in the NSInvocation return value. The main thread run-loop logic
finishs and drains the pool, thus releasing the remembered 'text' object.
Control returns to the Squeak VM, we grab the bogus object out of the NSInvocation returnValue, and die...
Part of this is also the question about scope, you see the object is valid within the context of the NSInvocation invoke, but invalid outside of that.
What you have to do is likely the following, use the code sample below (not tested) to extend the UITextView class so that you can send the message
textRetained to a UITextView instance to get the text.
Unknown is HOW many other gems exist in the UIKit that exhibit this behavior. But usage of NSZombieEnabled quickly identifies you have a problem.
@interface UITextView (SqueakOverrides)
- (NSString*) textRetained;
@end
@implementation UITextView (SqueakOverrides)
- (NSString*) textRetained {
return [self.text retain];
}
@end