On Oct 4, 2014, at 8:49 PM, Charles Jenkins <cejw...@gmail.com> wrote:
> Keary, I see you’re right: NSTableViewDelegate’s tableView:heightOfRow: will > be key if my stack of editors appears in a table view. I’ve been struggling > all day to get a test program to call my delegate’s functions. I must say, > the table view is a very disheartening object to work with. > > John, I am sort of doing a master-detail type of thing. I’m trying to > implement my own version of Jer’s Novel Writer. On the left side of the > screen, there’ll be an Outline View of a novel’s structure, with chapters and > scenes. On the right, a stack of text views. If a single scene is selected in > the outline, then the stack will contain one editor. But if a chapter is > selected, then there’ll be one editor for each scene within it. (Each scene > is stored in a separate RTF file in the document’s package file.) I think my > stack can be as large as needed without regard to the window’s height: the > whole thing will be contained within a scroll view. > > I tried working with the NSStackView yesterday, and it would only overlay my > subviews on top of one another, rather then presenting them in a vertical > column as expected. I created 16 variously sized NSBox objects and used a > loop to add each one to the top gravity of the stack view. Because the boxes > were different sizes, I could see that they were laid uselessly on top of one > another like cards in a deck. > > Today I’m using the same array of NSBoxes, but trying to put them into a > single-column table. My table-manager class acts as both a data source and > delegate, and because of breakpoints I know that my data source methods are > called as expected, as well as some delegate ones, but the methods important > to my needs are never called. The table view is set up as view-based in IB > and does not have a fixed row size. However, tableView:viewForColumn:row and > tableView:heightOfRow: are never called. > > I’ve struggled with these all day and still can’t figure out why the methods > that matter don’t get called. I copied the prototypes directly from the > NSTableView documentation and only renamed some variables. I’ve checked > several times that the table is configured to be view-based and has no fixed > row size. Assuming I’ve got the prototypes right, can anyone suggest reasons > why the table would call some delegate methods, but not the important ones > shown below? Sometimes the most obvious issue is the culprit--is the delegate outlet set? If so, are any other delegate methods being called? Note that you might not get a call for certain delegate methods if there is no data to show--i.e. if the table view doesn't otherwise believe it has data to show, either via bindings or data source methods. I suspect, however, that you will have better results from Jonathan's suggestion of a vanilla NSScrollView, especially if you are dealing with fixed numbers of "rows". You can have pre-made NSViews that you can swap in and out as its document view. The other types of views (NSTableView, NSStackView, NSCollectionView) are really for dealing with arbitrary numbers of elements, and are probably heavier than you need. HTH, Keary Suska Esoteritech, Inc. "Demystifying technology for your home or business" _______________________________________________ Cocoa-dev mailing list (Cocoa-dev@lists.apple.com) Please do not post admin requests or moderator comments to the list. Contact the moderators at cocoa-dev-admins(at)lists.apple.com Help/Unsubscribe/Update your Subscription: https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to arch...@mail-archive.com
