Ok, I'm in the process of developing my first iPad application. Yea I'm a newbie. I'm running into a number of problems implementing properties even though I'm using the exact same code as I used for the iPhone. I thought the two platforms were (are) the same iOS? For example, I can not set the Keyboard type for a UITextField either directly through Storyboard or programmatically. Here's what I've done:
storyboard
keyboard = number pad
programmatically
header
IBOutlet UITextField *txtValue;
#property (nonatomic, retain) UITextField *txtValue;
implementation
#synthesize txtValue;
txtValue.keyboardType = UIKeyboardTypeNumberPad;
I also tried:
[txtValue setKeyboardType:UIKeyboardTypeNumberPad];
Also there is an active IBOutlet for the UITextField between the ViewController screen and ViewController file in the Connections Inspector and the User Interaction enabled is checked.
There's absolutely nothing wrong with the default keyboard other than the fact that it's not what I want. Any idea what is going on here? Thanks...
I think I know what the answer is and it's pretty dumb. The answer is, there only is one keyboard on an iPad. The property only sets the configuration when it is opened. So if you set the Keyboard to NumberPad, the same keyboard opens up with the numbers showing. Not sure I like this.
That keyboard is not available on the iPad.
If you do not like the standard keyboard, I'd recommend you look into creating your own custom keyboard. Here is a document to help get you started:
http://developer.apple.com/library/ios/#documentation/StringsTextFonts/Conceptual/TextAndWebiPhoneOS/InputViews/InputViews.html#//apple_ref/doc/uid/TP40009542-CH12-SW2
All things considered, a custom iOS keyboard isn't as hard as it sounds. It's just another custom view. The hardest part is making some graphics to make it look the way you want.
If the custom route is not what you're looking for, there are also several "custom" keyboard people have already made. Checkout github or CocoaControls. Here is just one example of a custom number pad someone's made for the iPad:
https://github.com/azu/NumericKeypad
NumberPad is not a supported type on iPad.
(command/apple click on the UIKeyboardTypeNumberPad to see more about it)
Related
I have a NSStatusItem that displays a NSPopover which contains a NSTextField but the text field isn't editable although it has been so be so in Xcode. Now this is a known bug and there is apparently a solution someone posted here. I really need to work around this bug.
I'll just quote the answer here for convenience:
The main problem is the way keyboard events works. Although the NSTextField (and all his superviews) receives keyboard events, he doesn't make any action. That happens because the view where the popover is atached, is in a window which can't become a key window. You can't access that window in no way, at least I couldn't. So the solution is override the method canBecomeKeyWindow for every NSWindow in our application using a category.
NSWindow+canBecomeKeyWindow.h
#interface NSWindow (canBecomeKeyWindow)
#end
NSWindow+canBecomeKeyWindow.m
#implementation NSWindow (canBecomeKeyWindow)
//This is to fix a bug with 10.7 where an NSPopover with a text field cannot be edited if its parent window won't become key
//The pragma statements disable the corresponding warning for overriding an already-implemented method
#pragma clang diagnostic push
#pragma clang diagnostic ignored "-Wobjc-protocol-method-implementation"
- (BOOL)canBecomeKeyWindow
{
return YES;
}
#pragma clang diagnostic pop
#end
That makes the popover fully resposive. If you need another window which must respond NO to canBecomeKeyWindow, you can always make a subclass.
I don't really understand what I am supposed to do. Do I just create these two files NSWindow+canBecomeKeyWindow (.h and .m) and that will do it? Because it doesn't work for me.
I am not sure about this but does this only work if I am actually using an NSWindow that displays the NSPopover? I am not using a NSWindow, how can I get the NSTextField to be editable?
Thanks.
Yes, just add the NSWindow+canBecomeKeyWindow (.h and .m) files to your project, and it should work. I'm using this technique in an app I'm currently developing, and it works fine. Make sure NSWindow+canBecomeKeyWindow.m is listed under "Compile Sources" in your project's Build Phases.
As an aside, I'm having other issues using NSPopover to show a window from an NSStatusItem. I haven't actually tried using it in my project, but this looks promising as an alternative.
Recently I've been wondering about the fact that that an iOS app only has one UIWindow.
It does not seem to be an issue to create another UIWindow and place it on screen.
My question is kind of vague, but I'm interested in:
What could I potentially achieve with a second UIWindow that cannot be done in other ways?
What can go wrong when using multiple UIWindow instances?
I have seen that people use a 2nd UIWindow to display popover like views on iPhone. Is this a good way of doing it? Why? Why not?
Are there other examples where it is making perfectly sense to have another UIWindow?
It's not that I'm missing something. I have never felt the need to create another UIWindow instance but maybe it would allow doing amazing things I'm not aware of! :-)
I'm hoping that it might help me solve this problem:
I need to add a "cover view" over whatever is currently displayed. It should also work if there are already one or more modal controllers presented. If I add a UIView to the root controller's view, the modal controllers sit on top, so do the popover controllers.
If I present the cover view modally and there is already a modal controller, only part of the screen is covered.
Starting with Rob's answer I played around a bit and would like to write down some notes for others trying to get information on this topic:
It is not a problem at all to add another UIWindow. Just create one and makeKeyAndVisible. Done.
Remove it by making another window visible, then release the one you don't need anymore.
The window that is "key" receives all the keyboard input.
UIWindow covers everything, even modals, popovers, etc. Brilliant!
UIWindow is always portrait implicitly. It does no rotate. You'll have to add a controller as the new window's root controller and let that handle rotation. (Just like the main window)
The window's level determines how "high" it gets displayed. Set it to UIWindowLevelStatusBar to have it cover everything. Set its hidden property to NO.
A 2nd UIWindow can be used to bring views on the screen that float on top of everything. Without creating a dummy controller just to embed that in a UIPopoverController.
It can be especially useful on iPhone where there is no popover controller but where you might want to mimic something like it.
And yes, it solved of course my problem: if the app resigns activation, add a cover window over whatever is currently shown to prevent iOS from taking a screenshot of your app's current content.
A UIWindow can float above other UI elements like the system keyboard.
To address your last paragraph: Make a UIWindow with the same frame as your main window. Set its windowLevel property to UIWindowLevelStatusBar. Set its hidden property to NO.
Here is Apple's Documentation for better understanding UIWindow:
https://developer.apple.com/library/archive/documentation/WindowsViews/Conceptual/WindowAndScreenGuide/WindowScreenRolesinApp/WindowScreenRolesinApp.html
One good though specific reason to use multiple instances of UIWindow is when you need to video record the app screen. You may not want to include certain elements (recording button, recording status, etc.) in the final recorded video, so you can put those elements in a separate UIWindow on top.
In fact, if you are using ReplayKit, you will have to use a separate UIWindow for these excluded UI elements. More info here: https://medium.com/ar-tips-and-tricks/how-to-record-a-screen-capture-with-replaykit-whilst-hiding-the-hud-element-bedcca8e31e
I'm very new to Objective-C and Cocoa Touch. I have been following tutorials from a book. Currently I have a UITextField that is supposed to open the keyboard on a tap from the user to enter input.
However, when I run the app, nothing happens when I tap on the text field. I've checked all its attributes and made sure that it's enabled and user interaction is enabled.
Is there something really obvious I'm missing? I've read the tutorial two to three times, and I can't figure out what's wrong.
have you linked everything in interface builder (if you created the textfield by XIB)
Set that textfield as firstresponder. See How do I set the firstresponder?.
I am developing an interface for an OpenGL Simulation on the Mac using Interface Builder. All OpenGL stuff is being written in C++ (which I know fairly well). Unfortunately I have no idea about Objective-C.
Basically, I have a few NSTextField displaying info on an object selected on the Screen. Using these textfields the user is the able to manipulate the object on screen and then there is a Save Button and a Restore Button (which either save the new values or restore the original ones)
I have this all working. My problem is when I enter data into an NSTextField the "focus" of the windows seems to remain on the NSTextField (blue border remains around it).
I use the keyboard to interact with items within the NSOpenGLView, I need to pass the focus back to the NSOpenGLView when I hit either the Save or Restore buttons.
Sorry if this is a very straightforward question
Thanks
David
Have you tried using NSWindow makeFirstResponder method to make your NSOpenGLView the first responder?
Just managed to get it working.
I had to add the line:
[[NSApp keyWindow] makeFirstResponder: MyOpenGLView];
to the end of the function being called when I click on either of my buttons.
(Thanks Julio for pointing me in the right direction)
I've got a UITextView defined by
#property (nonatomic, retain) IBOutlet UITextView *quote;
in my view controller header, and I can set the value by using
quote.text = #"some text";
but the view doens't want to update the value, what can I do
Setting the text should immediately cause the UITextView to render your text under normal conditions.
Are you sure your that:
The UITextView is placed appropriately in your Nib and is visible?
The UITextView is appropriately linked with your outlet in your file owner (aka view controller)?
A quick test to verify the visibility of your UITextView - just place some sample text in it in the nib and verify that it appears on launch. If so, then you know that at least your view is displaying appropriately. At that point, it would have to be related to #2.
Make sure you connected quote to your UITextField in your XIB. Also, make sure that you #synthesize quote; in your .m.
I just bumped into this too and the problem went away as soon as I specified enough height for the content. In Xcode it may still look all right, but AutoLayout decided to do without the TextView if there was no height-constraint on it.
This was probably not your problem back when you asked the question, but it still turned up fairly early in my google search, therefore I post this answer anyway.
Btw: Xcode is still acting a little skiddish when you edit the constraint. It will update the view (and save) if you hit 'Enter' in the Constant-Field, but it will not do so if it loses focus in some other way.
This just to show us how difficult it is to get user interfaces right all the time.