So I'm putting my app's preference settings into the Settings app. One of the settings is an edit text field (PSTextFieldSpecifier). When touched, the keyboard dutifully appears, I can make the edits, but when I press Return....nothing. Well, the editing is completed, but the keyboard remains. I see no way to make the keyboard go away.
I also notice this same behavior in other Settings panes, including those from Apple. Do I assume correctly that this is just standard behavior and I need to just accept the fact that my Settings table has now been reduced to half size, and just deal?
Furthermore, I gather there is no approved way to have a "rich" child pane display, such as that seen in Settings->General->About->Legal? Or a way to do what appears to be a -presentModalViewController, a la Settings->General->Passcode Lock?
Unfortunately you have to deal with it. And there's nothing you can do in code, at least for now.
That's a bug that hasn't been fixed for a while. You should fill out a bug report.
You need to a call to resignFirstResponder ... e.g.
- (BOOL)textFieldShouldReturn:(UITextField*)tf
{
[tf resignFirstResponder];
return YES;
}
Related
To understand NSUserNotification better, I wrote a little test app playing with this class.
So far so good, except that no matter how hard I tried to feed the additionalActions property with array of NSUserNotificationAction objects, it never showed any difference but only one action button and a close one.
My expectation for this property is that the notification would show a pull-down menu containing the additional buttons I offer as it does in the Mac App Store update notifications.
Am I missing something? Or are you having the same problem, since it is a bug awaiting Apple to tackle?
Can you please try to click and hold down the action button in your notification? Does it show a drop-down menu of additionalActions?
Update
As it turns out, you can show the little chevron next to the action button by setting a true value for the private _alwaysShowAlternateActionMenu key on the notification. In Swift 3, it would look like this:
notification.setValue(true, forKey: "_alwaysShowAlternateActionMenu")
However, as I mentioned this is a private API and I strongly advise against using it if you want to distribute your App through the Mac App Store.
It is probably a bug. Setting up additionalActions will create the list, but not the little arrow icon. Holding down on actionButton will show the menu with the number of actions you set.
Besides setting additionalActions will cause several other problems. I will save this for another question.
Refer to another question.
show NSUserNotification additionalActions on click
P.S. I am using El Capitan APIs
in my app I need to create a bunch of UIAlertView popups expecting user to respond to each of them at some moment of time. By definition UIAlertView is non modal, i.e. the logic of my app continues to execute after making them. When the app would go into background would the popups be automatically saved? It looks like when user responds by clicking the button, correct popup responds even after app goes into bkgr and comes back. Does it mean that the UIAlertView popup ptrs are preserved during save/restore, ie can be reused after restore, OR, there is some mangling done to support clickedButtonByIndex:alert referring to correct popup?
Thanks. Victor
UIAlertView inherits from UIView, as does say a scroll view. These user interface elements are all "saved" when your app goes into the background, and are not mangled in some way. When your app comes back into the foreground all your UI elements work the same.
FYI, this behavior has changed in iOS 4 (in the unlikely event that you're trying to support pre iOS 4): See the "Important" note in the "Overview" section of the UIAlertView documentation.
But, yes, your app is preserved, unless iOS has to shut it down, in which case all bets are off.
My app has a UIWebView that is used for showing a PDF file. The file size is less than 1MB but when the user double taps the screen, the app freezes and crashes a few moments later.
I think that if I disabled the select function, maybe this problem wouldn't occur. How do I do that?
Have a look at the console output. It looks like you are not handling tap events properly. You must have those handlers even if you want to ignore tap events (i.e. do nothing and return).
Here's a good overview of what needs to be done:
http://mithin.in/2009/08/26/detecting-taps-and-events-on-uiwebview-the-right-way/
I have an app that uses UiWebViews, and I need to not show the keyboard for a text field within such a view. I provide my own buttons that insert the limited sorts of text the field allows, but I also need to allow pasting (I will filter what gets pasted) and adjusting the cursor position. Any way to do this?
It looks like this can't be done, I've researched it further and that's pretty clear. I don't want to accept a wrong answer, so I figured I'd just answer this myself and say: can't be done.
if you just want the textField do normal things except the showing keyboard action, you could subclass UITextField and overwrite the touchesBegan/Moved/Ended, just call super touchesBegan/Moved/Ended and add additional code which would hide the keyboard, if you have a reference to the keyboard ( you may figure it out urself how-to ), call the method : [keyboard resignFirstResponder], you may try to Category the UITextField class so you would have the reference to the keyboard ( if it's private ) - but not recommended because categorying may break our project design, but if you just need it for the only purpose, give it a try. Hope it helps.
The iPad virtual keyboard will disappear in one of (at least) these 3 circumstances:
If the control (say, a UITextField) programmatically resigns first responder.
If the user taps the "dismiss keyboard" button in the lower right.
If the user connects to the USB/keyboard dock peripheral.
In all cases, I get the UIKeyboardWillHideNotification.
The problem is that the first two cases are generally equivalent-- in other words, the user is done editing the text field. But in the third case, the text field is still being edited, just from another input source.
The problem is detecting the difference between cases 2 and 3. All I get in both cases is UIKeyboardWillHideNotification. In case 2, I generally want to also lock the edit control and commit the value. In case 3, I generally want to do nothing and allow editing to continue.
But how can I tell the difference?
Apple's Pages app seems to be able to distinguish this on document-title renaming.
I would look at the UIKeyboardBoundsUserInfoKey passed with the notification. The physical keyboard probably has empty bounds.
It sounds like you're just trying to figure out when a user is done editing. You could listen for the UITextFieldTextDidEndEditingNotification notification for cases 1 and 2.
A much simpler solution would be couldn't you just check against the editing property of UITextField to determine if it's still supposed to be editing or not? I don't have a physical keyboard, so I have no way to test this. I'm just guessing.
Here's a link to the documentation on that property: http://developer.apple.com/iphone/library/documentation/UIKit/Reference/UITextField_Class/Reference/UITextField.html#//apple_ref/occ/instp/UITextField/editing
I'm very curious to know if this works or not... :)