I am puzzled and could swear I set my NSSplitView holding priorities in IB some days ago, but now they don't seem to be visible in IB at all. Does anyone else see holding priorities in the top left of Xcode's IB when the splitView is selected ?
Does your split view have subviews? I can reproduce what you're seeing if I delete all subviews from a split view. That section shows one slider for each subview.
Update:
You are using the new NSSplitViewController and NSSplitViewItem classes introduced with Yosemite. Because of that, your split view does not, in fact, have subviews in the NIB. (There's no triangle toggle to disclose subviews under the split view.) The split view items will provide views on demand via their view controllers.
The holding priority is a property of the split view item. I can't verify at the moment, but I expect that Xcode will provide a means to set it if you select the individual items.
Related
In iOS, you have a concept of View Containment, is there such things in OSX?
Basically I want to create multiple nsviewcontroller each managing a specific view. I'd have a MasterViewController with a menu on the left (like ITunes), each time the user click on an item on the left, it would load the correct nsviewcontroller to display it's view.
Any tips to achieve what I need is appreciated
Thanks,
As of OSX 10.10 there is, watch Storyboards and Controllers on OS X.
Comment.
NSViewController did basically nothing (other that load NIBs) for years, I'm glad to see that it finally got from attention. Certain people in the Cocoa crowd here have a snotty attitude about the view controller programming style; I've asked questions like this before and had the "are you a iOS newbie coming to Cocoa" response. That's something that I never understood, it's a great model for containment, and reuse.
The main difference between OS X and iOS is that on an iOS device you have only one "window". On OS X there are desktops that can contain many windows that you can view and interact with at the same time.
In general, it sounds like you are trying to create an NSWindow that contains a single-column NSTableView for your list of choices on the left, and some other view that will display the detail of the selection on the right. It's common to place these within a vertical NSSplitView so the user can adjust their relative widths, but they could also stand on their own, as two separate subviews within the window's main view.
You typically use an NSArrayController to manage the list contents and track which particular item is selected. For your detail view on the right, you would use a single NSView with NSControl subviews that display values bound to the array controller's selected object.
If the data structure varies among your objects, swap in or show/hide various subviews as needed for the different types of data the particular selected object represents. You can use the "Conditionally Sets Hidden" binding option to automatically hide controls for which there is no applicable keyed value.
Alternatively, if there's a fixed number of objects in your list and their structures are all quite different from one another, then you may wish to use a tabless NSTabView that has a separate tab with its own custom view for each of your objects. Observe when the selection changes in your list, and select the appropriate tab accordingly.
Relating to UITableView sections to always stay within view but I got an idea I'm not sure of:
Has anyone ever tried to nest a UITableView in another UITableView, whether by putting the second one as the tableHeaderView or as a section header of the first one?
UITableView is derived from UIScrollView. It is generally not a good idea to have a scroll view inside a scroll view (exception: when the scrolling directions are perpendicular to each other).
Otherwise you would end up with a user interface that is not appropriate for most users.
I have a 10.6 app that I am building on Lion with Xcode 4.3
There is a horizontal split view in the main view, containing the following:
The top view contains an NSSearchField with an NSTableView below it.
The bottom view contains a WebView.
I have it working, but when I resize the split view the top view behaves oddly.
What I want to happen is for the search field to remain where it is, the tableview to remain where it is, but to expand if the split view is dragged down. If dragged up, I want the webview to overwrite the search field and table view.
You can see what I mean in this clip: http://dl.dropbox.com/u/160638/Work/TENSOFT/resizemostlyokay.mov
This keeps the things in the right place when I drag up, but doesn't expand the table when I drag down. The view is expanded, but not the table.
So, I changed the autosizing constraint on the table view / scroll view to make it expand when the view is resized. This is what happens: http://dl.dropbox.com/u/160638/Work/TENSOFT/resizeproblem.mov
When the split bar is moved upwards the table view is moved upwards inside the top view until it overwrites the search field. It doesn't move back when the bar is moved back down.
I cannot find a way to make this work by changing the autosizing constraints. This is usually pretty easy stuff, so either I'm missing something obvious or...?
Has anyone seen this behaviour before when creating SL apps on Lion with Xcode 4.3?
FYI, if I replicate this in a new 10.7 project using auto-layout everything works fine.
Regards
Darren.
When you allow an NSSplitView to make one of its subviews very small so that the subviews effectively overlap you get layout issues and this is one of the reasons that Apple introduced auto-layout (watch the WWDC video about auto-layout and I think they demo this problem near the beginning).
If I were you I'd set a minimum size for the top pane so that, for example, it stops resizing when it is 100px high. You can then allow it to collapse so that the user can still show just the WebView.
I have an NSCollectionView that I want to accept items dragged from elsewhere in my application.
I implement collectionView:validateDrop:proposedIndex:dropOperation: and collectionView:acceptDrop:index:dropOperation: in the collectionview's delegate and register for the appropriate dragged types. Both methods get called fine when I drag the appropriate types, but I don't get a blue focus ring over the collectionview indicating a valid drag.
Have tried both the collection view and its containing scroll view on Default and External settings for the focus ring. Both are just the standard non-derived Cocoa classes. Wondered if there was anything else I should try. Surely it isn't necessary to subclass NSCollectionView for this?
Thanks
Chris
Focus rings are not typically the correct way to provide feedback about drag destinations. Every view does it slightly differently. NSTextView shows the insertion bar. NSTableView shows a blue line in between rows for Before drop operations, and shows a bezel around the row for On drop operations. (See NSTableViewDropOperation)
NSCollectionView shows a "gap" between existing subviews to show where the items will be dropped for Before drop operations, and it will set the selected property on NSCollectionViewItem to YES for On drop operations. (Note: NSCollectionViewItem doesn't do anything by default to visibly represent the selected property. You must implement that yourself.)
Since NSCollectionView's feedback uses existing subviews only, it appears there isn't any feedback at all for empty NSCollectionView's. You would need to subclass to provide this behavior yourself. You could also file a bug to request that NSCollectionView do this itself.
I subclassed UITableViewController and called it FeaturedGamesViewController. Ok, I also have a navigation controller to which I added this FeaturedGamesViewController as the root. All pretty standard stuff that you do in the App Delegate.
Also note that there is no NIB file created for FeaturedGamesViewController. Just subclassing UITableViewController and calling initWithStyle sets the style of the table and sets the dataSource and delegate and size automatically. Data Source and Delegate are obviously set to FeaturedGamesViewController.
- (id)init
{
// Call the superclass's designated initializer
[super initWithStyle:UITableViewStyleGrouped];
}
OK, You see that I have set the table size to "Grouped". In Landscape view on my iPad it has about 20 pixels of space to the top, left and right (Sorry can't post screen shot because I am new here and the system won't let me until I have accumulated a certain number of points)
I DO NOT want that! This is Landscape so I expect it to fill up the all the space between the navigation bar and the tab bar below. What is worse is that I have faked a grid with a Custom UITableViewCell but the space to the left and right make it so that if you click on that space, the entire row is selected thus betraying the sense that this is a grid.
Now I figure I should resize the table view in viewDidLoad or something but I don't know how. I cannot do initWithFrame because of potential memory leaks (and possibly resetting dataSource and delegate and autoresizeMask properties that were already set) so there must be a setter or something to reset the origin of the tableview to just beneath the Navigation bar and filling up the entire screen with size 1024X748. How do you do dynamically reset the size of the table view?
Then I got really frustrated and I decided to do it via a Nib file, that way I can set the the orientation to landscape and set simulated Navigation and Tab bars and fill the rest of the space with the table view. This worked! If you are curious how to create a table view with a Nib after you have subclassed UITableViewController WITHOUT a nib, here is how:
http://developer.apple.com/library/ios/#documentation/UserExperience/Conceptual/TableView_iPhone/CreateConfigureTableView/CreateConfigureTableView.html#//apple_ref/doc/uid/TP40007451-CH6-SW10
Go to the paragraph right before "Creating a Table View Programmatically".
OK, when I did that, my landscape view of the "grid" looks filled up the entire space between the navigation bar at the top and the tab bar at the bottom just like I wanted.
I was fiddling with this some more and I found out that in my "non nib" version (the problematic one), I had set the table style to "grouped". When I changed it to "plain", it worked!!! But here is the thing though: In the nib version, "grouped" or "plain" gives the correct layout with the table occupying the whole space. So what gives?
Sorry for the long question but I guess what I am asking is:
1) How do you programmatically reset the size of the table view without introducing potential memory leaks or affecting other properties already set for you (ex: dataSource, delegate, autoResizeMask - these are set for you just because you subclassed UITableViewController)?
2) How do you do that for any view in general?
3) Why does "plain" style fill the layout as desired whereas "grouped" style gives the weird layout. Note that it this is not a problem in the Nib version.
Thanks for your patience!
Answer for (2), and hence for (1):
A UIView's frame is in a local coordinate system of its superview. A common way to make a view fit its superview is
CGRect bounds = [[self superview] bounds];
[self setFrame:bounds];
You should do this inside layoutSubviews.