My iPhone app (based on the "Single View Application" of Xcode) has a UITextView (say: myTextView) that I want the user to be able to edit. I was setting it to editable, and all was working fine (I didn't even have to invoke becomeFirstResponder).
Then I moved it in another UIWindow (say: newWindow) (on top of the main/root/key one that is called self.window (of the Single View App.)).
But now, when I click on the UITextView, the keyboard does not show.
Everything works if I do this:
[myTextView setEditable:YES];
[myTextView becomeFirstResponder]; // ugly...and I do not need it, but I added it just in case...
[self.window addSubview:newWindow];
but the keyboard is shown immediately (since I set becomeFirstResponder) that is not nice.
But if I remove the becomeFirstResponder line, the keyboard does not show at all!
If I move the [self.window addSubview:newWindow] line above, then no matter what I do, the keyboard is not activated...
[self.window addSubview:newWindow]; // this is how it should be... but,
[myTextView setEditable:YES];
[myTextView becomeFirstResponder]; // even when I enter this, it's not working :-(
I tried [newWindow makeKeyAndVisible] nothing. I tried to add a touch delegate and detect a touch (or a gesture) on the UITextView, they work (I get the NSLog message I included), but again, no keyboard. I even tried to add another field (of the main window) on top of newWindow (so as to have a main window element on top), still no luck...
What am I missing?
You shouldn't add a UIWindow as a subview. Instead, windows are shown either by calling -[UIWindow makeKeyAndVisible], or -[UIWindow setHidden:NO] if you don't want it to receive key events.
It's rare that you need to use multiple windows though. Just using a normal UIView add adding that as a subview will do in many cases.
EDIT: I had a confusing remark before about "assigning to a screen". UIWindow has a property "screen", which you can assign to if you want to display the window on another screen than the main screen. You don't need to care about that for your use case, though.
Related
I have an application that displays a CFrameWnd that is displayed on top of the main window. I need the window to be non-movable and non-resizable when the user selects a certain mode for the window.
My CFrameWnd is created with the styles WS_OVERLAPPEDWINDOW | WS_THICKFRAME | WS_POPUP
I have come across a solution using an overload of CWndOnNcHitTest to rewrite
HTLEFT,HTRIGHT,HTTOP,HTTOPLEFT,HTTOPRIGHT,HTBOTTOM,HTBOTTOMLEFT,HTBOTTOMRIGHT,HTSIZE,HTCAPTIONto HTBORDERto prevent the framework to recognize the areas responsible for sizing / moving.
This method works well for resizing in my case, but moving the window is still possible, although the hittest override works correctly (verified with traces).
Is there anything wrong in my approach, or could there be something interfering with this solution and if so, do you have any tips on where to look?
You should be able to make OnNcHitTest() work, don't return HTCAPTION.
Still, there's more than one way to move/size a window, you also have to worry about the system menu (type Alt+Space). Write a message handler for WM_MOVING and WM_SIZING and override the RECT so the window stays put.
I use a subview (UIView) with labels, text and buttons to connect to a server. Works OK. When finised and successful i need to close the subview to revert to its parent view. This happens in a delegate of the OK button of a UIAlertView, within the subview. (equivalent of Me.Close in VB.net)
Any suggestion? Could not find any docu so far.
Use UIView.RemoveFromSuperview() to remove it, see Apple doc. I would also call Dispose() on the view.
Another alternative is to use a UIViewController and PresentModalViewController(), this is generally how you show a popup view over another.
I use an UIScrollView to set the position of a CCLayer (when i drag with the finger). It work fine but in this CCLayer i've got a CCMenu with one button CCMenuItemImage.
When i click on this button it's ok. But if i press the button and drag just a little bit the layer, the button stay pressed and become not responsive.
thanks for your help
The UIScrollView interferes with the touch events received by CCMenu. It was never designed to share its touches with a UIView.
You have these options:
find and fix the issue by modifying the CCMenu class
write your own menu class
don't use UIScrollView or disable its touch input while the menu is active
I think you'll need to modify CCMenu and attempt to disable the scroll view's ability to scroll on touch. Have a look at the UIScrollView properties called scrollEnabled and delayContentTouches.
By the time the CCMenuItem callback has been called, it might already be too late.
I have a table listing some strings, and what I want is when I tap the add button on the navigation bar, a keyboard with a textField would jump up, so I can input a string in the textField, then when I tap the return key, the keyboard disappear as well as the textField, and the new string is added to the table.
I already make up a nib file with a toolBar containing a textField, and I just failed to go on.
How can I implement this idea? Use the inputAccessoryView? If so, that means the inputAccessoryView of the textField which belongs to the toolBar is gonna be the toolBar itself!
This seem kind of weird and I have not been able to make it work till now.
Or is there another way for this idea?
Thanks a lot!
I've solved the problems by using notification instead of inputAccessoryView.
There is a sample code in XCode called "KeyboardAccessory", and it gives a good example about using keyboard notifications!
Or custom a view with a tab, and set it as the textField's inputAccessoryView, that would also work!
I have attached a toolbar with a UITextField and UIButton to the keyboard when it becomes the first responder via the user taping inside the textfield
textField.inputAccessoryView = theToolbar;
Problem is, the toolbar disappears when the keyboard is dismissed, thus preventing any further input.
Any ideas on how to make the toolbar go back to the bottom of the screen rather than off it completely?
I'm thinking a delegate method might help but Im really not too sure. It seems once the inputAccessoryView always the inputAccessoryView :(
Cheers
The input accessory view is automatically dismissed with the input view (the keyboard, in this case). Generally you do not want to have an input accessory view in your view hierarchy. Instead, if you want your toolbar to scroll up when the keyboard is shown, you should follow the guidelines for Managing the Keyboard.
You could try using an additional toolbar that is offscreen as the inputAccessoryView, which could "fake" the appearance of what you are trying to do. Alternatively, have you tried adding the toolbar back to the bottom of the screen using
[self.view addSubview:theToolbar];
when the keyboard reaches the bottom of the screen? You can use keyboard notifications for this.