Re: A Stack of Editors
Re: A Stack of Editors
- Subject: Re: A Stack of Editors
- From: Keary Suska <email@hidden>
- Date: Sun, 05 Oct 2014 07:51:13 -0600
On Oct 4, 2014, at 8:49 PM, Charles Jenkins <email@hidden> 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 (email@hidden)
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:
This email sent to email@hidden