Apologies in advance if this is answered but I genuinely couldn't find it. I'm trying to bring up the keyboard type on iPad which appears when pressing the "#+=" button. I've tried going through all the types on the docs and I'm sure that this wasn't successful. Am I missing something or does the user have to click this button every time?
Edit: this question was closed as "off-topic" because it didn't include code or ideas or what I've tried already... Therefore for a bit of extra detail, I used EVERY keyboard type that is available on the docs e.g.
theTextField.keyboardType = UIKeyboardTypeNumberPad;
This did not yield the results that I require, which is the keyboard plane that appears when you press the #+= button because I wanted users to go straight to that one.
Unfortunately, this is impossible. It's not a keyboard type you want, it's a keyboard plane. There is no public API to switch or in any way access the keyboard planes.
One solution could be to create your own keyboard with the symbols you want. Another solution would be to open the keyboard and then generate a touch event that will switch the keyboard plane. However, this would be complicated, non-portable and a bit dangerous.
You have no ability to affect the built-in keyboards.
You can however create your own custom input view which you would set on the inputView of your text editing view before you make it first responder. Then iOS will show this view instead.
Have a look at this project of mine which implemented a "Morse keyboard" (April Fool's joke), but demonstrates how to achieve a custom keyboard that still interacts with a text field as you'd expect. http://www.cocoanetics.com/2012/04/dtmorsekeyboard-tutorial/
Related
How can I automatically scroll the view up when I focus in a TextInput box and a keyboard is shown such that the TextInput box is not hidden behind the keyboard?
This question has been asked on StackOverflow a few times and I implemented the solution here which is the general solution advised in most of the answers. This solution works fine in the iPhone simulator but doesn't work on the actual phone. Has anyone else experienced this problem that the solution doesn't work on the actual phone?
Second thing that I noticed after adding this solution is that now if I am focussing in a TextInput box and keyboard is shown, if I press a button or try to focus into a different TextInput box, the first touch is always consumed to hide the keyboard and the button is not pressed or the other TextInput box is not focussed. It is a little annoying for the user to have to do the operation twice. Has anyone else observed this problem?
Please let me know if you have any inputs on how to solve these problems?
I assume you are using this solution. I ran into the same problem and made some adjustments (see gist). I addressed both problems you describe. keyboardShouldPersistTaps solves your second problem.
I have not found the exact reason why the spacing works in Simulator but not on a real device. It has something to do with the timing. The original code sets a timeout on input focus and tries to scroll down after 50ms. Increasing this to for example 500ms makes it work on devices too, but I don't really like adding magic timeouts that I don't understand. I changed it, so onFocus I look up the element to scroll to and store a reference. When onKeyboardDidShow fires I use the reference.
I have a form in my Cocoa app that contains an NSSegmentedControl that I want to be controllable via the keyboard. It seems that NSSegmentedControl is very reluctant to become the first responder, however.
Setting the initial first responder of the window to the segmented control does nothing -- it will not have keyboard focus when the window is first loaded. It does receive focus if I manually set the first responder like this, however:
[segmentedControl.window makeFirstResponder: segmentedControl];
That will work fine if the only part of the form is the segmented control. If I add another field (say, an NSTextField), and I set the nextResponder of the segmented control to that field, the segmented control will never become first responder. Focus will immediately go to the text field, and pressing tab to switch back to the segmented control doesn't work.
I've tried subclassing NSSegmentedControl and overriding acceptsFirstResponder, becomeFirstResponder, etc. to no avail. The only one that makes any difference is resignFirstResponder -- if I return NO from that method then the segmented control will indeed retain focus, but obviously I don't want it to retain focus all the time.
Any ideas on how to get the control to behave like a normal responder?
It's behaving as intended. Not all controls participate in the "key view loop". Full keyboard navigation is turned on through Universal Access in System Preferences for all apps and it's not for individual apps to implement on their own.
It's best not to use a segmented control in a form intended for heavy keyboard entry. NSPopUpButton works more closely to what we all exepect in a web form so it's not as if it's necessarily the wrong choice in your app's UI.
Rather than answer exactly the question you asked (which someone else can do), I humbly suggest you choose on the side of functionality at the cost of a slightly prettier UI element since that prettier UI element wasn't intended to get along with the keyboard.
Is it possible to change what each key does? I have a client application and the way it needs to work is that each key press is a command to send over the network. I do not need my keyboard to produce letters (the server will do this) when pressed but commands to the server. Currently I have this working by making a custom view that looks like a keyboard however it would look better if it was the ios default keyboard.
Of course I dont expect the code but I need a starting point. My current google searching hasnt gone to good. Maybe a link to an example or some documentation on how to do it.
notes: you will see the first answer below makes a good suggestion but it brings up another point. my keyboard needs to mask the keyboard of the server, so no .com button or any other out of the ordinary keys, so I would also need to edit the layout I guess.
Create a text field with a custom delegate, hide it and set it as the first responder. Then you can hook into the delegate methods to work out what was pressed.
I'm developing a iPad app which has a popover which appears to show you a list of items. I need the ability to delete one of the items, so I'm considering adding the ability to press-and-hold (a.k.a. long tap) on one of the list items which would show another popover for that item, with an action list showing a delete button.
Two questions:
In terms of iPad UX, is this a good idea? Haven't seen it anywhere, and I guess it could be a little confusing...but how else can I do this?
Is this possible, code wise? I haven't tried it, but I am still pretty new to iOS development so I could see myself fumbling round for hours before finding out there's a technical reason why it's not possible.
Thanks!
It's not a good idea, and I don't think it's possible even though it's possible.
Apple's Human Interface Guidelines clearly state that you should not do it. This is as definitive an answer as there can be regarding UX.
For inspiration on how to delete items without requiring a popover, look at how UITableView does it, for instance.
Often, you'll have an Edit button in the top toolbar inside the popover to trigger edit mode.
If you want some kind of confirmation dialog, use UIActionSheet. They look good and work well enough, especially in popovers. In your case, I think these are the way to go.
I have a application with a tab view when the user clicks in the menu for example "client data" I generate a tab programmaticaly. Now I want to subclass the tab view to add a close button for each NSTabviewitem. If you don't have an answer you could help with documentation or sample code
I know this question is ancient, but...
I spent some time trying to add buttons to NSTabViewItems with a custom subclass, and as far as I can tell it's not really possible. NSTabViewItem simply isn't customizable enough to do the job.
My suggestion is to take a look at chromium-tabs or perhaps PSMTabBarControl; they have a different appearance than standard NSTabViewItems, but provide out-of-the-box functionality for icons and close buttons.