My app has multiple UITextViews and touching a text view causes the background to change color. But after a few touches the app crashes.
My app crashes with EXC_BAD_ACCESS when the user touches a UITextView (it doesn't crash on the first touch, but after some random number of touches) No help from the stack trace or zombies.
I have replicated the problem with one UITextView and minimal code shown below. The code given causes a EXC_BAD_ACCESS when the UITextView is touched a few times..
#import "ViewController.h"
@implementation ViewController
@synthesize text_view_1;
#pragma mark - View lifecycle
- (void)viewDidLoad
{
[super viewDidLoad];
// Do any additional setup after loading the view, typically from a nib.
[text_view_1 setDelegate:self];
}
- (BOOL)textViewShouldBeginEditing:(UITextView *)textView
{
//Code to change textview background colour will go here
return NO;
}
Is this UITextView hooked up/connected in the xib? Otherwise you are referencing it without the property being setup for you. Setup the delegate of the UITextView in the xib. Rather than on the load method. It should be in the init method or you can set it in the xib... to avoid threading (re-entrant) issues with these references to self and UITextView.
Is this UITextView hooked up/connected in the xib? Otherwise you are referencing it without the property being setup for you. Setup the delegate of the UITextView in the xib. Rather than on the load method. It should be in the init method or you can set it in the xib... to avoid threading (re-entrant) issues with these references to self and UITextView.
Thanks for the reply.
I tried setting up the delegate in the xib (and deleting the setDelegate call). The end result is exactly the same behavior.
Are you running this in Simulator on 4.3? If so, go to settings and turn off the auto correct and anything that is on. See if the problem persists. I had a similar issue and doing this resolved it for me.
It's just a but with the Simulator I believe.
EDIT: I had this issue with the UITextField ... but it's worth a shot
How do you handle the touches on the UITextViews? Your code seems ok so the problem must be somewhere else.
Also you don't need to define
- (BOOL)textViewShouldBeginEditingUITextView *)textView;
in your .h file because it's a delegates method.
Thanks I deleted that from the .h file but the problem persists.
The code I posted above is all it takes to cause the problem. There is no other touch handling and no other additional code in my project apart from the xcode generated single view stuff. I was having the problem in a much larger project but managed to localize the problem to the few lines of code I posted.
Are you running this in Simulator on 4.3? If so, go to settings and turn off the auto correct and anything that is on. See if the problem persists. I had a similar issue and doing this resolved it for me.
It's just a but with the Simulator I believe.
EDIT: I had this issue with the UITextField ... but it's worth a shot
Hi, I am running on simulator 5.0. But I also have the problem on my iphone running the latest ios.
I had Capitalization and Correction off but still I have the problem. Thanks for the suggestion.
UPDATE: The problem seems to be specific to the simulator and devices running ios 5....
My app was selling fine on ios 4 but the bug reports started to come in after ios 5 was released. Also, I can reproduce the problem with the above code on ios 5 but not ios 4. I'm pretty stumped now.
I wonder is there a work around... Any other way to cause a UITextView to change background color when touched but not show the keyboard?
First of all, I make it a point never to retain an IBOutlet (by indicating strong). AFAIK, IBOutlets, even when not declared as properties are by default retained.
Before you try something a little involved, changing the @property to a regular declaration.
if that fails:
If you need to manage the touches for your UITextField, create a method in the View Controller that handles the touch, make sure it's a - method not a + method. Then make a subclass of UITextField that handles the touches. Use this:
In InterfaceBuilder, remember to set the UITextField to the class of the custom text field. Also make changes to the declaration of the instance variable.
Code:
// In the main view controller header (MyMainViewController.h)
- (void)customTextFieldWasTouched:(NSSet *)touches withEvent:(UIEvent *)event;
// In the main view Controller (MyMainViewController.m)
- (void)customTextFieldWasTouched:(NSSet *)touches withEvent:(UIEvent *)event {
// Handle the event
}
// In the UITextField subclass
- (void)touchesBegan:(NSSet *)touches withEvent:(UIEvent *)event {
MyMainViewController *mmvc = [[MyMainViewController alloc]init];
[mmvc customTextFieldWasTouched:touches withEvent:event];
[mmvc release];
}
First of all, I make it a point never to retain an IBOutlet (by indicating strong). AFAIK, IBOutlets, even when not declared as properties are by default retained.
You might get away with it using only an instance variable, but:
1) If you DO add a property, then the behavior of that property will be whatever you define it to be. So if you define it as an assign property, then you've overridden whatever behavior might have been applied to the instance variable alone. The XIB loader looks for properties first via KVC, and only uses instance variables if they aren't found.
2) As a general guideline, you should always use properties.
3) Also as a general guideline, anytime you want to make sure that an object remains alive on your terms, you should retain it. This means using a retain property. That way if Apple changes their minds about how XIBs load, it won't affect you. This is less of an issue with ARC, but still sound advice.
Combined, you are making it a point to do the wrong thing. Chances are that the only reason you haven't been bitten by this (or didn't realize you had) is that you haven't removed any IBOutlets from their superview intending to use them again later. Or ARC has been saving your bacon.
Quote:
Originally Posted by fhsjaagshs
Before you try something a little involved, changing the @property to a regular declaration.
So you are creating a brand new view controller, sending it a message, and then getting rid of it. How does that help pass a message along to the view controller that is already alive, already managing the view that is already on the screen?
Wow. I have absolutely no idea. Unfortunately you are using both ARC and Storyboards, so I can't help very much and the things I would want to try I can't do. I tried different names, I even added a text view to the iPad Storyboard, no change. Crash after the 2nd or 3rd tap.
If I return YES, then it seems to work just fine. So it would seem to be an issue with returning NO, but I have no idea why that would matter.
Wow. I have absolutely no idea. Unfortunately you are using both ARC and Storyboards, so I can't help very much and the things I would want to try I can't do. I tried different names, I even added a text view to the iPad Storyboard, no change. Crash after the 2nd or 3rd tap.
If I return YES, then it seems to work just fine. So it would seem to be an issue with returning NO, but I have no idea why that would matter.
I'm afraid I'm stumped. Sorry.
very strange indeed. I attached a project with no storyboard and no ARC to this, but the behavior is the same. It is only the ios 5 sim and devices that crash but ios 4 works fine.
Now that I know your machine is giving the same result, maybe I should post a bug report on the apple site...
Thanks
I even - uh, don't tell anybody this - checked the retain count, and if anything the number was higher than I expected. My vote is for Apple bug. It sure does act like an over-release. I wouldn't even know what to change to work around it, other than to allow editing. Maybe swap back and forth between a label for reading and a text view for writing, although that would be challenging if you need to scroll.
Hi all
I confirm that I also have this issue only on the simulator, my iPad running iOS 5.0.1 seems to take this correctly.
What I am doing, I have subclassed the UITextView so that I can respond to the method - (BOOL)canBecomeFirstResponder so that this memo will be in read only mode but allow scrolling when the text is viewed only and not edited.
First click in the simulator runs ok, but will crash every time with the second click in it.
This may have something to do with an internal gesture recognizer of this control.
I can see this as the last code label before it crashes:
_ZN2TI8Favonius10BeamSearch20choose_hit_test_nodeE RKN3WTF6RefPtrINS0_10SearchNodeEEERKNS3_INS0_11Key AreaNodeEEES7_S7_+14>
I would also vote for an Apple bug.
Quote:
Originally Posted by BrianSlick
Yep, still an issue.
I even - uh, don't tell anybody this - checked the retain count, and if anything the number was higher than I expected. My vote is for Apple bug. It sure does act like an over-release. I wouldn't even know what to change to work around it, other than to allow editing. Maybe swap back and forth between a label for reading and a text view for writing, although that would be challenging if you need to scroll.
I've been playing around a bit to go around this issue and found, if I can say this, something.
Instead of just preventing the control from going in Edit mode based on the delegate method or by doing what I just did, that is subclassing the UITextView and overriding canBecomeFirstResponder, just use the editable property.
By setting this guy to NO, you still get the scrolling feature to work and also, TADA, no crashes.
I still believe this is some sort of bug in the API itself. I've trace the machine code and with the labels we see in there, we can see that we are going through the GestureRecognizer code. And still stranger, I have another UITextView, shown this time in a Popover, and this one never crashes...
Anyway, I'll be looking more closely at properties next time, editable is the key!
Hope it helps!
Eric.
Quote:
Originally Posted by BrianSlick
Yep, still an issue.
I even - uh, don't tell anybody this - checked the retain count, and if anything the number was higher than I expected. My vote is for Apple bug. It sure does act like an over-release. I wouldn't even know what to change to work around it, other than to allow editing. Maybe swap back and forth between a label for reading and a text view for writing, although that would be challenging if you need to scroll.
Thanks for the input.
I need my UITextView to change background color when touched so it has to stay editable.
I ended up switching to UILabels for the time being.
regards
DrSpike, did you ever resolve this with UITextView? Anyone know if an apple bug was ever identified for this? I have a similar occurrence where I get an EXC_BAD_ACCESS because either a UITextTapRecognizer or UIVariableDelayLoupeGesture object is released one time too many down in UIKit or Foundation, which I found by enabling zombies and profiling the app.