I have an NSView (we'll call it view1) that is from an NSViewController. The Super view (which we'll call view2) is located inside an NSWindowController. The problem is, I can add view1 to view2, but I can't remove it.
From your comment I'd guess one of your instance variables to the view controller or the view itself isn't being set correctly, so you're calling removeFromSuperView on nil. Use the debugger to explicitly see the state of the objects involved.
Related
I have a storyboard that contains a main window (with a corresponding MainWindowController class), and a main view (an NSSplitViewController, with corresponding MainViewController class). For certain functionality I am attempting to set the delegate of the NSSplitView contained in the view to the MainWindowController class.
Without any IB linkage, the NSSplitView delegate is already set to the MainViewController at application launch. I am able to get a reference to the MainWindowController, but when I attempt to set the delegate to the window controller (which does implement NSSplitViewDelegate), I am getting the following:
*** Assertion failure in -[NSSplitView setDelegate:], /Library/Caches/com.apple.xbs/Sources/AppKit/AppKit-1404.34/AppKit.subproj/NSSplitView.m:600
This also happens if I attempt to set the delegate to nil.
Does anyone know why this might be so, whether there are restrictions on setting delegates, and if there is a way to use IB to set the delegate of an item in a view to another Controller?
Thanks.
I don't have a reference for this but I'm pretty sure the split view and the split view controller aren't meant to be separated. Fortunately, NSSplitViewController mirrors the delegate methods, giving you a chance to intervene. There should therefore be no reason to change the split view's delegate.
I created UITabBarController with each tab contain UINavigationController and set rootviewcontroller in this UINavigationController, all of this is done in interface builder. In viewDidLoad I try to get frame size from view, but when I reference view it return null. Have anyone experienced this before.
All IBoutlet are properly connected.
viewDidLoad returning a nil view if the view is connected in your .xib could mean:
For programmatic initialisation (custom controllers):
You forgot to call initWithNibName:bundle: on the view controller class altogether (you may have called init or something instead).
You've overridden the loadView method in your view controller class, but it doesn't set the view.
For all controllers:
An outlet connection hasn't been made correctly.
You have accidentally released the view or view controller before showing it.
The nibName parameter was not properly specified when initialising the view (the nib could not be found or one without a view was found.. though this should also throw an exception).
There wasn't enough memory to allocate the view (the app would likely have been terminated by that point though).
I'd recommend you try doing frame size calculations in viewWillAppear: instead and see if the view is still nil at that point.
Do I put such things into the display method? Or is there something analogous?
As of OSX 10.7:
- (void)layout is equivalent to layoutSubviews
There is now an identical setNeedsLayout.
Override this method if your custom view needs to perform custom layout not expressible using the constraint-based layout system. In this case you are responsible for calling setNeedsLayout: when something that impacts your custom layout changes.
You may not invalidate any constraints as part of your layout phase, nor invalidate the layout of your superview or views outside of your view hierarchy. You also may not invoke a drawing pass as part of layout.
You must call [super layout] as part of your implementation.
Analogous to layoutSubviews is the resizeSubviewsWithOldSize: method of NSView. I guess, analogous to setNeedsLayout would be calling resizeSubviewsWithOldSize:[self frame].size directly.
resizeSubviewsWithOldSize: seems like it does nothing. Never gets called at all for me. Maybe it's because I use autolayout and the documentation says it's related to autoresizing.
NSView's layout appears to be the same as UIView's layoutSubviews. They're both overridable if you want to do some special work to replace or in addition to autoresizing or autolayout.
Calling this on UIView
[view setNeedsLayout];
seems to be the same as this on NSView
view.needsLayout = YES;
Which begs the question, why is "setNeedsLayout" even a function name? Like, really, you decided to remove the parameter from a setter function, and keep the "set" in the title? Why not "scheduleLayout"? This would obviate the need for Stack Overflow questions like this.
Sometimes, resizeSubviewsWithOldSize doesn't get called.
Then, try overriding resizeWithOldSuperviewSize.
I created a view Called ProgrammaView that appears when a row of a table is clicked.
This view has a UILabel, a UIImageView and a UITextView.
Now.
ProgrammaView's Outlets have to be changed by the parameter passed to a method of the view called iniz.
in this
image there is first the ProgrammaView.h and then the method iniz.
The problem is that the label and other stuff doesn't change!
I checked 3 million times that everything between the xib file and the controller is linked.
The trick to call iniz in the other viewcontrollers works well in other part of the program so i think is not that the problem.
Thank you in advance!
You need to call setNeedsDisplay to indicate that the view should be redrawn.
My understanding is that you start up and show view after that you update the values and expect the view to display new values.
You need to call setNeedsDisplay to indicate that the view should be redrawn. Try to add it at the end of your iniz method.
See apple doc.
When a class is customized, by using its outlet , you cant access its method. Is there any better solution to access the method of a customized class? without posting notification?
To be more specific, sometimes when a Controller Class having outlets of other classes, could
access the method of the corresponding classes. But the reverse is not always true. Why is this behavior?
You don't put a class in an outlet, you put an instance there. That's because a nib never contains classes, only instances.
And you most certainly can send messages to objects in outlet variables. The view, where by “view” I mean the object that's in a controller's outlet, can't talk back to the controller only if the view does not have an outlet of its own that's connected to the controller. So, give the view an outlet to the controller.
Note that the nib system treats outlets as properties, so you'll want the controller's outlet to be retaining (unless the view is a subview of another view, or the content view of a window) and the view's outlet to be non-retaining (assigning). If both properties are retaining, you'll have a retain cycle.