UIKeyboard is not visible after reload a view - uitextfield

We've a UIViewController for login on our application, the first load works perfectly, but after a logout, when we back to the login page, we detect some unexpected problem for 6.1 version.
I configure the events keyboardDidShow and keyboardWillHide based on notifications, because the Keyboard appear out of the screen.
If I print the CGRect of the keyboard based on the UIKeyboardFrameEndUserInfoKey, the behavior is very estrange:
First field: {{inf, inf}, {0, 0}}
Second field: {{160, 487}, {0, 0}}
Additionally the interfaceOrientation is always unknown when the problem appears.

Solved.
On the didFinishLoad / AppDelegate we had this code:
self.window.rootViewController = self.viewController;
[self.window addSubview:self.viewController.view];
I replace it (removing the first line):
// Add to the windows the iForceViewController view
[window addSubview:viewController.view];
Is a crappy solution, because we include the first line in order to solve unexpected behavior on rotations.
Thanks

Related

Unexpected nil window in _UIApplicationHandleEventFromQueueEvent

One of my old apps is not working with iOS8. When I start the app up, and try to tap on the screen anywhere, I get this message in my console:
unexpected nil window in _UIApplicationHandleEventFromQueueEvent,
_windowServerHitTestWindow: <UIWindow: 0x7fe4d3e52660; frame = (0 0; 320 568);
opaque = NO; autoresize = RM+BM; gestureRecognizers = <NSArray: 0x7fe4d3e2c450>;
layer = <UIWindowLayer: 0x7fe4d3e86a10>>
I'm using an old style MainWindow.xib. In the MainWindow.xib is my Window object, as well as a UINavigationController which has its first View Controller defined within as well. The image below is showing the Outlets connected to the App Delegate.
The white "view" in the screenshot below is the UIWindow. The view on the right is the UINavigationController (nav bar hidden) with the first ViewController defined inside it.
How do I fix this without recreating the entire app from scratch with a new project?
EDIT: I just discovered there is a TINY strip wherein my buttons will actually receive their taps/clicks.
I've also noticed that my self.view.window is nil. How do I make sure that is set?
Additional to B H answer. Also look this answer.
Got this issue when launching my landscape only app from portrait orientation (also the app shouldn't be presented in recently opened apps list, which can be seen by pressing Home button twice. Perhaps, iOS somehow caches the orientation and window size).
My code was
self.window = [[UIWindow alloc] initWithFrame:[[UIScreen mainScreen] bounds]];
[self.window makeKeyAndVisible];
I set W+H autoresizing mask for window, it didn't help me, because the window don't being resized on rotation, but the transform matrix is changed.
The solution is simple
self.window = [UIWindow new];
[self.window makeKeyAndVisible];
self.window.frame = [[UIScreen mainScreen] bounds];
So the frame is set AFTER the window get its orientation from root view controller.
You don't have to add any code to fix this.
Open the main xib file and find "Window" from the left side and enable Visible at Launch and Full Screen at launch.
Check out your Window nib file and make sure it is taking up the full screen. I had a similar issue on my app where touch events weren't being registered on a strip on the right side. Once I set my MainWindow.xib to take up the Full Screen, I had no more errors and touch events were working again. My app was also being displayed in Landscape but my MainWindow.xib had portrait dimensions.
Sometimes it's just simple setting that's missing some value: Click on Project(whatever you named your project) name item then make sure General tab is selected and scroll to the bottom. Look for App icons and Launch Images make sure there is some value in the Launch Screen File field, this should be either Main or LaunchScreen
In case somebody finds this useful:
In my case, I had used
self.window = [[UIWindow alloc] init];
instead of
self.window = [[UIWindow alloc] initWithFrame:[[UIScreen mainScreen] bounds]];
and that was the reason for the problem.
I was getting this error on an old app that did not have the Default-568h#2x.png launch screen. When the taller iPhones were first introduced, this was the signal to iOS that the app could handle the new geometry. Otherwise, it was displayed in a 320x480 window. Funny, I did not even notice the app was not using the full screen.
I wasn't able to test efpies solution, but the way I fixed it in my app was to replace the MainWindow.xib with a Storyboard.
We had the same issue, and we tried the proposed solutions in this thread without success.
What ended up working for us, was to re-write the logic to be pure programmatically instead of using xib's. After this we don't see the 'unexpected nil window' error and the view is getting the hit all over the screen.
In case this helps anyone else that stumbles here, I also got this error when I had the UIScreen.mainScreen().bounds size flipped when setting the window's frame.
I am also upgrading my old project to iOS 7 and iOS 8.
Actually, I don't use MainWindow.xib, but creating window manually in application:didFinishLaunchingWithOptions:.
But i have same unexpected nil window in _UIApplicationHandleEventFromQueueEvent error after launch.
So, in my case, problem was solved by changing deployment target to 6.0 and replacing code in main.m:
Old main.m:
int main(int argc, char *argv[])
{
NSAutoreleasePool *pool = [[NSAutoreleasePool alloc] init];
int retVal = UIApplicationMain(argc, argv, nil, nil);
[pool release];
return retVal;
}
New main.m:
int main(int argc, char *argv[])
{
#autoreleasepool {
return UIApplicationMain(argc, argv, nil, NSStringFromClass([YourAppDelegate class]));
}
}
In my case it was an old code and after reading the complete code i found this line
UIApplication.shared.delegate?.window??.isUserInteractionEnabled = false
I handle it according to my logic and it's working now.
It worked for me to Enable windows user interaction.
window.isUserInteractionEnabled = true
Using the new ios 8 'nativeBounds' UIScreen property instead of 'bounds' when creating the window fixed the issue for me. No other changes required.
self.window = [[[UIWindow alloc] initWithFrame:[[UIScreen mainScreen] nativeBounds]] autorelease];
To support previous version too, I do a runtime check with the version:
if([[[UIDevice currentDevice] systemVersion] floatValue] >= 8.0)

Adding a UIDatePicker as an inputView to a textField in iOS 8

I have an UIDatePicker in my storyboard view connected to an IBOutlet in the header file.
In the implementation file I set some properties to the picker and then assign it to my textFields:
[self.txtEndDate setInputView:self.picker];
This was working fine in iOS 7, but with iOS 8 it's giving me the following error:
Terminating app due to uncaught exception 'UIViewControllerHierarchyInconsistency', reason: 'child view controller:<UICompatibilityInputViewController: 0x7c2d8800> should have parent view controller:<InserimentoDurata: 0x7aec2b10> but requested parent is:<UIInputWindowController: 0x7b92b400>'
Any idea on how to fix this?
After receiving an email from Apple's Developer Technical Support, it seems that to add a UIDatePicker (or any custom keyboard for what I've understood) to a viewController, you don't have to add it to its view anymore, but you add it to its title bar and then connect it to the IBOutlet.
It's working for me, even if it doesn't work in the iPhone 5 simulator (all the others are ok) and I was going nuts.
I hope this could be of help for other people with the same problem.
The solution is to build your UIPickerView in code (remove it from the Storyboard), assign it to the textfield's inputView, and retrieve it from there anytime you need it (instead of keeping a reference to it). Basically, this means:
UIPickerView* picker = [[UIPickerView alloc] initWithFrame:CGRectMake(0, 300, 320, 168)];
[picker setDataSource: self];
[picker setDelegate: self];
picker.showsSelectionIndicator = YES;
self.textField.inputView = picker;
If you later need it, use:
UIPickerView* pickerView = (UIPickerView*) self.datePartySizeTextField.inputView;
[pickerView selectRow:1 inComponent:0 animated:NO];
UIDatePicker should not be child of any super view
Problem:
You have to ensure that the view you will assign to inputView or inputAccessoryView don't belong to any parent view. Maybe when you create these views from xib inside a ViewController, by default they are subviews of a superview.
Solution Tips:
Using method removeFromSuperview for the view you will assign to inputView or inputAccessoryView
see detail in this link
Error when adding input view to textfield iOS 8

Modal dismissals do not account for status bar (new iOS 6 issue?)

Didn't have this issue at all until I began adapting my app for iOS 6. Whenever I return from a modal segue (with dismissViewControllerAnimated:completion:), my main view is shifted up by about the status bar's height worth of offset (and is subsequently behind the status bar).
The only workaround I've found is to add:
self.navigationController.view.frame = CGRectMake(0, 20, 320, 460);
self.view.frame = CGRectMake(0, 0, 320, 416);
to my dismissViewControllerAnimated:completion method (those values are for an iPhone < 5 and are just for explanation). But this doesn't really solve the problem, because when I go to present the next modal view controller, the presented view is then shifted up by about the status bar's height worth of offset.
No idea how this issue arose. My suspicion is that, somewhere in the segue, one of the navigation controllers loses track of the status bar's existence (linked to the new status bar, in some way?).
EDIT:
a screenshot of the main view, post-modal dismissal. [Note: 20px whitespace on the bottom]
Resolved the issue. My custom navigationController's supportedInterfaceOrientations was returning UIInterfaceOrientationPortrait, rather than UIInterfaceOrientationMaskPortrait.
Your answer didn't work for me either but I found this solution by Mike Foster that did:
http://fostah.com/ios/2012/09/27/ios6-orientation-handling.html
His steps are:
add the applications supportedInterfaceOrientation and have it return UIInterfaceOrientationMaskAll (or in my case I used AllButUpsideDown)
In your rootViewController implement shouldAutorotate and have it return NO
DO NOT implement supportedInterfaceOrientations in your rootViewController (this seems to be the step that was causing problems with the status bar for me)
In the viewController that should be landscape implement shouldAutorotate to return NO and supportedInterfaceOrientations to return UIInterfaceOrientationMaskLandscape
Hopefully that helps a few other people.
This answer didn't work for me, even though I have the same structure with a custom navigationController as the rootViewController. In my app, I want it in portrait for all VCs except for my modals, which will be UIInterfaceOrientationMaskAll.
What did work was a variation on your workaround, except it will account for iPhone 4 and iPhone 5 screen sizes and the height of the navBar:
[yourParentVC dismissViewControllerAnimated:NO completion:^{
[yourParentVC.view setFrame:CGRectMake(0, 0, [UIScreen mainScreen].applicationFrame.size.width, [UIScreen mainScreen].applicationFrame.size.height-44)];
//your other completion code
}];
+1 for asking this question...not happy how much work it's been accounting for all the deprecations in iOS 6, so every little bit helps.

Programmatic equivalent of "Visible at Launch" for NSWindows

I'm trying to write the programmatic equivalent of a nib file I've setup that contains two windows: a main window and sheet that appears after launch to prompt for credentials. Wiring these up in IB works fine, so long as one remembers to uncheck the "Visible at Launch" box on the sheet/window.
However I can't figure out what the API equivalent is of "Visible at launch". When I run my app using the programmatic version the sheet is detached and not the key view in the same way my app ran with the nib when "Visible at Launch" was checked. So my assumption, then, is that I'm missing the secret visible-at-launch sauce.
Does anyone know how to do this?
P.S. I know how to make this work in IB, I specifically want to figure out the code equivalent so please don't tell me to just use the nib. I know that.
NSWindows are typically created hidden. So you shouldn't have to do anything; just don't show the window until you need it. Here's a simple example.
NSWindow *sheetWindow = [[NSWindow alloc] initWithContentRect:NSMakeRect(0, 0, 100, 100) styleMask:NSTitledWindowMask backing:NSBackingStoreBuffered defer:NO];
NSTextField *field = [[NSTextField alloc] initWithFrame: NSMakeRect(25, 25, 50, 50)];
[[sheetWindow contentView] addSubview:field];
[NSApp beginSheet:sheetWindow modalForWindow:[self window] modalDelegate:self didEndSelector:#selector(sheetDidEnd:) contextInfo:NULL];
The text field obtained keyboard focus when I ran the above.
In future, please provide code in cases like this—it's a lot easier to correct existing code than to write new code.

NSTextView not refreshed properly on scrolling

I have a NSTextView with a sizeable quantity of text. Whenever I scroll however, the view isn't updated properly. There are some artifacts that remain at the top or the bottom of the view. It appears that the view doesn't refresh itself often enough. If I scroll very slowly the view updates correctly though. If I add a border to the view everything works perfectly, borderless view is the one that has a problem. Here's a link to a screenshot:
Thanks
Have you set the setDrawsBackground and copiesOnScroll propertes for either the NSScrollView or the NSClipView?
The first thing I would suggest is turning off the "draws background" property of the NSScrollView:
[myScrollView setDrawsBackground:NO];
Note that this should be set on the NSScrollView, and not on the embedded NSClipView.
The following excerpt from the documentation may be relevant:
If your NSScrollView encloses an NSClipView sending a setDrawsBackground: message with a parameter of NO to the NSScrollView has the added effect of sending the NSClipView a setCopiesOnScroll: message with a parameter of NO. The side effect of sending the setDrawsBackground: message directly to the NSClipView instead would be the appearance of “trails” (vestiges of previous drawing) in the document view as it is scrolled.
Looks like the text field isn't even in the scrolling-area... Are you sure something isnt overlapping it?
I had a similar trouble - artifacts develop when the NSTextView is embedded in another scrollview (ie. a NSTableView).
I actually turned on the setdrawsbackground, and then added a nice color to make it disappear again.
-(void)awakeFromNib{
NSScrollView *scroll = [self enclosingScrollView];
[scroll setBorderType:NSNoBorder];
[scroll setDrawsBackground:YES];
[scroll setBackgroundColor:[NSColor windowBackgroundColor]];
}
This in combination with a scrollWheel event let me use the NSTextView in a NSTableView.
-(void)scrollWheel:(NSEvent *)theEvent{
NSScrollView *scroll = [self enclosingScrollView];
[[scroll superview] scrollWheel:theEvent];
}
I had the same trouble some time ago. I don't remember how I solved it.
Try to place the NSTextView to another view if the superview is a custom view. Just to see what will happen.

Resources