When I transition between view controllers, the two latest ones I have created, in the debug, I am getting a large string that I'm not quite able to get to the bottom of.
Can anyone point me in the right direction/ help me to understand this and find the problem I've made?
I have compared all of my documents/view controllers to my working/non-error ones and can't find anything obvious.
2019-02-12 18:47:20.879463+1300 Techsupport[15324:9474292] <UIView:0x7ff96154a2f0; frame = (0 0; 375 812); autoresize = W+H; tintColor =UIExtendedSRGBColorSpace 1 0.149131 0 1; gestureRecognizers = <NSArray:0x600002c474e0>; layer = <CALayer: 0x6000021d42c0>>'s window is not equal` to <Techsupport.EslViewController: 0x7ff9618fd800>'s view's window!
It's easier to read if you take out all the details about the view:
Techsupport[15324:9474292] <UIView>'s window is not equal to <Techsupport.EslViewController: 0x7ff9618fd800>'s view's window!
It's hard to know exactly what's going on without seeing some of your code, but fundamentally the view that the error is complaining about (located at 0x7ff96154a2f0) belongs to a view hierarchy in a window that's different from the one that the view controller's view is in.
Here are some things to consider:
How are each of these views created?
Do you expect to have two windows? (Most iOS apps only have one.)
What are you trying to do with the view in question?
A good way to start is to set a breakpoint at the spot where the error occurs, and then work backward until you figure out where the view in question comes from.
As #Sachin Vas said, "it looks like you have a segue which is set to trigger automatically and also programmatically in the code." he was correct, I did have a mistake where I had called the function programmatically as well as automatically. Thanks for everyone's help!
Related
Lately Ive been working with moving my frame to make up for the 20point gap when the status bar is not showing in landscape mode. I have finally gotten what I want, yet there is one problem that kind of annoys me. Let me explain: First I was using a call in viewDidLoad to move the frame, but that doesn't do anything to the frame, because I suppose the frame gets drawn after viewDidLoad. So I tried placing my call in viewDidAppear. That works smoothly, but sadly the user "sees" the repositioning; you can watch the frame being replaced with the bare eye. So I was wondering if theres anything I can do to prevent this, any workarounds. (just for good explanation this call is to take care of view frame when the user updates/go to another view controller when already in landscape. I have other functions to take care of rotation; which obv works)
Any help appreciated. I tried to be as specific as possible.
Thanks!
I'm having an issue with my app's layout which is a bit tricky to explain. When the app first starts, this is what I'm showing:
After the user taps "Create Profile", I animate those buttons and show a registration form instead:
Needless to say, the buttons are now not in their "natural" position. Note, however, that the text fields are - that's where I have placed them in the storyboard, but when the view first loads I hide them. The animations are working great, but then I needed to scroll my view up when the user gives focus to a text field and the keyboard hides the field. The details of how to trigger the bug are a bit hard to explain, so I managed to boil it down to what seems to be a redraw event, except that it isn't... Let me try and explain that.
First of all, here's what happens when the keyboard is about to show:
- (void)keyboardWillShow:(NSNotification*)notification
{
CGRect frame = self.view.frame;
frame.size.height -= 1;
self.view.frame = frame;
}
Notice that this is a test only, probably the minimal I found that would still trigger the bug. All it does is resize the view. I would expect the view to be exactly as it was, with one less pixel, right? Wrong. Here's what I get:
That is, all elements returned to their "natural" positions, completely ignoring their previous positions. My first guess was that it would seem that the window is redrawing, so I tried this:
- (void)drawRect:(CGRect)rect
{
[super drawRect:rect];
NSLog(#"View was drawn");
}
But this only triggers when the window is first drawn, not when this strange behaviour happens. To understand what I mean by "natural position", here's what I have in storyboard:
You can also see that I'm not using constraints and the underlying structure of my view:
The full code for the entire setup is quite extensive, so pretty much not practical at all to show. However, how I animate the subviews resumes to changing their frame as I did in keyboardWillShow, and setting their positions to whatever I need.
Any ideas?
So you're using storyboards and you have "Use AutoLayout" set to false for your entire storyboard?
In that case your app is using "struts and springs" style placement rules. You're going to have to debug those.
It's a bit hard to describe everything in a view controller in a post. It's easier to go over it in IB. Perhaps you can write a utility function that logs all the autoresizingMask values for the views in your view controller, and go over those, and perhaps post them here describing the autoresizingMask values for each view in your original post.
I'm trying to make a inputAccessoryView AND the keyboard modal for VoiceOver users so they don't get lost. Setting:
view.accessibilityViewIsModal = YES;
textField.inputAccessoryView = view;
Makes the view modal with keyboard visible but unusable - it is outside of the modal view.
Next I tried this after the keyboard has appeared:
textField.inputAccessoryView.superview.accessibilityViewIsModal = YES;
Which seems a bit out of bounds but almost worked - but the keys physical after B (N, M space, etc) were not navigable.
Next up was this:
textField.inputAccessoryView.superview.superview.accessibilityViewIsModal = YES;
and everything works just fine. That view, BTW logs as follows:
<UITextEffectsWindow: 0x17170290; frame = (0 0; 320 568); opaque = NO; gestureRecognizers = <NSArray: 0x17170710>; layer = <UIWindowLayer: 0x17170430>>
My question is this: I this a stupid thing to do? Seems like it. Is it legal? UITextEffectsWindow is private, but I'm not actually using it, just taking advantage of the fact that it's a view.
Any input or ways to work around the problem would help.
It's not illegal, but it is safe to assume it will stop working in future versions of iOS.
For example, in iOS 6, a developer could get from a cell to its tableview by calling self.superview. In iOS 7, there is now a private-classed view in between.
You may want to take a more dynamic approach, like traversing up the view hierarchy until you find a view with the correct frame, or with all of the views you need as its subviews. A similar approach for the UITableViewCell problem can be found here.
I know this has been asked before, but none of these solutions work, and that's the reason of my posting. Please do not close before considering my case.
My plist already has UIViewControllerBasedStatusBarAppearance = false.
I have already tried applying deltas, but to no result.
Changing the top level view frame in ViewWillAppear (like self.view.frame) did not succeed.
I thought of increasing the view height (storyboard attribute inspector), in combination with deltas, but my top level view X, Y are disabled in storyboard attribute inspector.
My main view doesn't have any children views because I load them into main view either dynamically or load them from XIBs which are again shared by more than view controllers. These XIBs provide layout for both Portrait and Landscape. I don't know what approach is ideal for this kind of configuration, but I would like it better if solution lies along these lines.
This approach worked partially, but gave me inconsistent results.
What makes the solution tricky is the fact that I have to support all 4 orientations - this is something I handle in code via didRotate and willRotate delegates for my other views, but failing to do it for statusbar.
Please help...
Could this link be of any help?
You might have to use the new setEdgesForExtendedLayout: method to get this working consistently?
Also, have a look at these official docs if you haven't already done so.
I ended up writing my own function to shift my all subviews (remember, not top level views whose frame is fixated by IB).
It didn't spoil my work but imagine if this was the case for a very big project with so many screens, the limitations would have made it a nightmare.
I have perhaps a strange VC structure here that I just made a bit stranger, causing it to break
UIViewController (contains->) UIContainerView (embeds ->) UIScrollView (contains ->) UIView
I have the final UIView because I couldn't figure out how to make the scrollview adhere to certain size restrictions so I just added a "content view".
Problem is, now the "content view's" data isn't loading
The Logs for the contentview are:
<UIView: 0x81cd510; frame = (-306 0; 612 792); autoresize = TM+BM; layer = <CALayer: 0x81c2000>>
The Logs for the Scrollview are
<UIScrollView: 0x81e5e90; frame = (0 0; 0 0); clipsToBounds = YES; opaque = NO; autoresize = W+H; gestureRecognizers = <NSArray: 0x81e67b0>; layer = <CALayer: 0x81e6060>; contentOffset: {0, 0}>
so it appears to not be loading... what gives? How to I make it load?
Edit to clarify:
All of these views were created though IB
Not using AutoLayouts (although that sounds interesting)
The NSLog methods are called in ViewDidAppear in the viewcontroller at the top of the view hierarchy chain. (Perhaps this is the issue?)
Edit: uploaded the project to github so that people can take a looksie
https://github.com/Pinwheeler/ChiroMatic.git
I spent quite a bit of time going through your project and, frustratingly, I was not able to deduce what was causing the problem. But I found I was able to fix the problem by recreating your PrintViewController and PrintContentViewController scenes (and I had to recreate both to fix the problem). I created a fork of your project and fixed the two scenes. I tried to annotate my changes in both the source code as well as the git repository commit comments, so hopefully you can follow what I changed. My fork is available at:
https://github.com/robertmryan/ChiroMatic
(Just let me know when you want me to remove that repo. I'm happy to remove it whenever you want, as I assume you don't want me to leave a copy on github indefinitely.)
A couple of observations:
You say that you're not using autolayout, but you are. (Go to the first Document Inspector tab on your storyboard and you'll see that "Use Autolayout" is checked.) That's fine if you want to use it (it's now the default in Xcode) but be forewarned that you lose backward compatibility to iOS versions prior to iOS 6 if you use it. Autolayout is powerful, but it can be tricky when you first start using it. It's your call.
In your PrintContentViewController, my most significant change was to use the standard view controller scene configuration (where the top level view is a UIView), and I made the UIScrollView a subview of that. Having said that, I don't think you needed the UIView subview of the UIScrollView (and it's problematic as you lose some scroll view functionality if you have that intermediate UIView), so I removed that, and made all of the labels and the like subviews of the scroll view itself.
You're using container views all over the place, but it strikes me that you're adding a level of complexity that's unnecessary. (And, by the way, you wouldn't have had the problem raised in your original question if you didn't use these container views.)
Custom containers are very useful when you want to abstract the logic associated with the container view controller from its child view controller. But you're not doing that here. Worse, you're going through all sorts of gyrations to grab the IBOutlet references of a child controller and updating the properties in the container controller. I'd heartily encourage you to reconsider your use of these container views and just excise them from your project entirely.
If you have a compelling need for the container views, fine use them (I love them and use them all the time), but I don't see any need for it here, and you're making life much more complicated for yourself.
Also, by the way, the use of the embed segue is an iOS 6 feature only, which can be an issue if you need iOS 5 backward compatibility.
Bottom line, I never was able to reproduce your problem when creating a new project and mirroring your storyboard. Nor was I able to eliminate your problem by any edits to your old PrintViewController and PrintContainerViewController scenes. I was only able to fix it when I recreated these scenes, and when I did that, it just worked.
I left your old scenes there (prefacing the segues with "old" so the storyboard wouldn't get confused), so maybe you can spend time figuring out what's wrong, but I don't see it. Maybe there was some bug in the storyboard that is evading me. Maybe there's some setting I'm not seeing. All I know is that when I just recreated it, copying your controls to my two new scenes, it just worked.
Personally, I'd advise cutting the Gordian knot, and just eliminate the container views altogether. Your code will be cleaner, and these sorts of issues are less likely to rear their ugly heads.
This isn't a satisfying conclusion (to not know what caused the problem), but at least it appears to be fixed. Good luck.