I am getting a warning I do not fully understand every time I run my app:
Layout still needs update after calling -[WebHTMLView layout]. WebHTMLView or one of its superclasses may have overridden -layout without calling super. Or, something may have dirtied layout in the middle of updating it. Both are programming errors in Cocoa Autolayout. The former is pretty likely to arise if some pre-Cocoa Autolayout class had a method called layout, but it should be fixed.
(I've seen this related question, yet the answer provided solves some other issue, thus my question.) The warning appears as soon as I add a web view to my app. What does it mean, and how should I fix the issue?
It appears that - (void)layout is implemented in WebHTMLView. The source for WebKit is available on Apple's open source page to review.
http://www.opensource.apple.com/source/WebKit/WebKit-7534.53.11/mac/WebView/WebHTMLView.mm
In the Auto Layout documentation, it states that you only need to implement "layout" if you need custom logic to layout subviews while using Auto Layout. It goes on to say that you should always call [super layout] in your custom implementation. That is not happening with WebHTMLView.
https://developer.apple.com/library/mac/#documentation/Cocoa/Reference/ApplicationKit/Classes/NSView_Class/Reference/NSView.html%23//apple_ref/occ/instm/NSView/layout
This message can probably be safely ignored for your project. The same thing happens for me on a blank new project.
Besides the noted NSTableView with dragging I found out that if you open the NSFontManager this will always show this message. Not only with Swift but also with Apple's own demo program CoreTextArcCocoa. So it's definitely some bug in Apple's guts.
Related
I'm experiencing weird crash in NSOutlineView: when i click "collapse" button, app crashes immediately and even "exception breakpoint" doesn't help to see where the problem is.
I've tried to run app without debugger, and reproduced the problem. Once app crashed, i've got OSX crash window and was able to extract crash message from there:
The window has been marked as needing another Update Constraints in Window pass, but it has already had more Update Constraints in Window passes than there are views in the window
there also call stack, but it won't help since crash happening inside libsystem_c.dylib, so i'm not posting it here.
It seems there is something wrong going with auto layout. Absolutely have no idea about next steps. Please give me an advice!
Also, one more thing, that began only after update to OSX Mojave.
After hours of debugging and testing, i noticed that that message is caused by "infinite layout loop".
Different code, related to outline view was causing NSSplitView to layout. And delegate method - (CGFloat) splitView:(NSSplitView*)sender constrainMinCoordinate:(CGFloat)proposedMinimumPosition ofSubviewAt:(NSInteger)dividerIndex has been called about 200 times prior to crash.
It's hard to catch this bcs it's not actually infinite recursion, so just debugger doesnt help a lot.
I just added simple code that helped me to identify the issue:
static int a = 0;
NSLog(#"Layout: %d", a++);
Hope my experience will help somebody else!
For anyone who is having the problem in Xcode 14 and macOS using SwiftUI:
I just had the same crash by hiding a view with an animation. My main view contains two views, one view contained an empty ScrollView, which didn't cause a problem by itself, but by changing it's size it crashed. Just adding a basic Text within the ScrollView solved my problem and the app doesn't crash anymore.
I updated my build to IOS 14 and Mac OS 20.15.6 and the error went away.
try turning off 'Use Auto Layout' checkbox in nib (in File Inspector tab).
May have to disable it for each and every view.
Also, unrelated, but Mojave forces you to use Core Animation.
Most of my nibs have 'set wants layer' turned off.
However, in one of my nibs I had a stray setWantsLayer checkbox checked.
when I unchecked it, the view (NSSearchField) drew properly
I am developing the Mac OS port of an iOS App and do face a problem with NSManagedObjectContexts when using NSArrayControllers in the Storyboard based Cocoa app.
It's kind of a follow-up question to:
Storyboard with TabViewController in OS X Application - Core Data Array Controllers in each scene?
I do have some ViewControllers presented like in a TabBarController, showing the same CoreData Entities. They are loaded through NSArrayControllers, that are hooked up with InterfaceBuilder.
From my existing knowledge, it was no problem to get the data on the screens. Even editing and saving to CoreData works.
But I realized, that every Storyboard scene got it's own instance of the NSArrayControllers and each its own NSManagedObjectContext.
When changing and saving the data on one screen, it is NOT updated on the other screens, that are all bound through the IB bindings and work in all other cases. They are just showing the data, they have loaded initially and are not updating automatically.
I think the problem is, that the changed data from contextA is not merged (or synced) to the other contexts of the other screens.
What is the best way of doing that? Should I use the NSManagedObjectContextDidSaveNotification for this?
That would mean, I would have to write much code, to manually start merging the changes from one context to all the other NSManagedContexts. Does smell really bad to me. I think there must be a much easier way, that I am not aware of and unable to find out about.
If you do have a hint for me, please just stick me in the right direction.
Thanks for that already.
Problem solved, I did a thumb error with Cocoa Bindings: I just dragged an object in the storyboard to every scene and set that to the AppDelegate. I just instantiated several AppDelegates with this, very bad idea! I corrected this, referencing the AppDelegate through properties on my ViewControllers and now it works as it should be. IB just has its little edges, where one has to be totally aware, about what is happening.
Just got this error in our error logging system, been searching hi and low and can't seem to find any solution. Any help is appreciated. Here is the stacktrace.
May be in your XCODE log you might have encountered this message
"Presenting view controllers on detached view controllers is
discouraged ".
If yes then then try
[self.view.window.rootViewController presentViewController:myVC];
if this fails then make sure you call presentViewController:myVC on immediate presenting ViewController i.e. in your case what I see from trace - CalendarEventDetailViewController.
If that too fail then go backward - from where you are invoking VC which in turn use presentViewController, in iOS8 presentation layer has changed specially WRT UIAlert/UIActionSheet, and UIPopovers,
if you are using any of these, create UIAlertController as a separate code track for iOS8 and use presentViewController:myVC on presenting ViewController.
I was facing similar issue where presentViewController: not working at all or disrupting presenting VC contents, in some situations dismissViewController was crashing. Using this approach I could fix it.
RBLPopover is a Popover made by the Guys from Github that aims to mimimc NSPopover but fixes some of it's flaws, like canBecomeKeyWindow. It is part of the Rebel Framework they currently hosting on GitHub. I decided to use this Popover for my Statusbar Application and ran now into a problem. NSPopover is able to resize it's size dynamically and animated if it's shown and you use setContentSize. Then it will automatically resize animated to the newly given size. However, RBLPopover is not doing that. After 8 hours on looking into RBLPopover's Code I was not able to fix this, one reason will be lag of knowledge on my Part on how Views work internally in Detail.
The Code for RBLPopover can be found here:
https://github.com/github/Rebel/blob/master/Rebel/RBLPopover.m
Can someone give me a hint on how to fix this? I don't ask for code, just some advice/concept on how to achieve this. Is there some Method that is missing in it's parent class? I don't believe that showRelativeToRect:ofView:preferredEdge: is the right method to change. I believe that something more fundamental is missing but I don't get it.
I have found one bug that causes the cocos2d view to stop rendering its contents. The bug can be reproduced using the example project found in Jpsarda's post about integration between UIKit and cocos2d-x.
The link to the website is: http://jpsarda.tumblr.com/post/24983791554/mixing-cocos2d-x-uikit and the link to the project is: http://dl.dropbox.com/u/12856650/Cocos2dxOnUikit.zip.
To reproduce the bug it is sufficient to trigger several times between uikit views and cocos2d views by pressing repeatedly the "Cocos2d-x GO!" button on the first view followed by the "Close" button on the second view. I have also done a video that shows how to reproduce the bug: http://youtu.be/EIvf-Ao6u5I. The bug occurs only on a real device and not on the simulator. Because of this bug it is pretty difficult to create applications that allow the user to switch frequently between cocos2d views and uikit views such the one on which I am working. For the moment I can't understand the root cause and I haven't received a reply on the forum yet. Is there anyone that have an idea/intution/suggestion about the possible cause?
I found the reason. EAGLView is never released and this causes a leak of resources. To resolve the bug in JPSARDA's example it is sufficient to add the following line:
[[EAGLView sharedEGLView] release];
at the end of CCEGELView::release method. This will solve JPSARDA's ( and my application :D ) issues but it is likely that this solution won't work in projects that handle EAGLView's lifecycle in a different way