NSOutlineView中的NSTextView的IntrinsicContentSize设置了错误的高度 [英] NSTextView in NSOutlineView with IntrinsicContentSize setting wrong height

问题描述

我有一个outlineView，其中放置了NSTextViews，这些NSTextViews在编辑时会调整大小(请考虑一下Outliner应用程序).我已经完成了大部分工作，但是某些行为却不一致.

I have an outlineView in which I am putting NSTextViews that resize when edited (think outliner app). I have most of this working, but some behaviour is inconsistent.

在我的NSOutlineView上设置:

On my NSOutlineView I set:

outlineView?.usesAutomaticRowHeights = true

对于单元格视图，我将NSTextView子类化.我设置了以下自动布局位:

For my cell-views I subclass NSTextView. I set the following auto layout bits:

self.translatesAutoresizingMaskIntoConstraints = false
setContentHuggingPriority(NSLayoutConstraint.Priority.defaultHigh, for: NSLayoutConstraint.Orientation.vertical)

我在NSTextView上覆盖了固有的内容大小计算:

And I override the intrinsic content size calculation on the NSTextView:

    override var intrinsicContentSize: NSSize {
        guard let manager = textContainer?.layoutManager else {
            return .zero
        }
        print("\(manager.usedRect(for: textContainer!).size)  \(string)")
        return manager.usedRect(for: textContainer!).size
    }

(我在上面的代码中在layoutManager上调用了sureLayout，但没有添加任何内容)

(I was calling ensureLayout on the layoutManager in the code above but it adds nothing)

intrinsicContentSize添加到大纲视图时，每个文本视图都会调用两次.第一次返回的大小是正确的，但是在第二次调用时，某些文本不必要地自动换行.下面显示了用于4个文本视图的internalContentSize上的两个遍的打印输出.列宽为281，因此这些字符串均不应包装.他们的第一遍都适合一条线(14高)，第二遍则是最后两个字符串绕行，这很奇怪，因为它们不是最长的字符串:

intrinsicContentSize is called twice per text view when they are added to the outliner. The first time the size returned is correct, but on the second call some of the text wraps unnecessarily. A printout of the two passes on intrinsicContentSize for 4 text views are shown below. The column width is 281, so none of these strings should wrap. The first pass they all fit to one line (14 high), on the second pass, the last two strings wrap, which is strange because they are not the longest strings:

(178.744140625, 14.0)  New pointwddwek kelekwelek...
(100.720703125, 14.0)  Related Subjects
(119.400390625, 14.0)  Related Publications
(87.150390625, 14.0)  Related Terms

(178.744140625, 14.0)  New pointwddwek kelekwelek...
(100.720703125, 14.0)  Related Subjects
(74.705078125, 28.0)  Related Publications
(54.484375, 28.0)  Related Terms

相同的字符串始终会导致相同的行为.例如.字符串相关主题"永远不会换行，字符串相关条款"总是会换行.

It is consistently the same strings that result in the same behaviour. E.g. the string "Related Subjects" never wraps, the string "Related Terms" always wraps.

呈现视图时，即使认为usedRect值暗示也不会实际包装文本.文本可以正确显示，但是大纲视图中的行视图太高，因为它认为有两行文本.

When the views are presented, the text is NOT actually wrapped, even thought the usedRect value implies that it would be. The text is shown correctly, but the row view in the outliner is too high because it thinks it has two lines of text.

我可能会缺少某些东西的指针吗?将同一字符串放入其最后计算的宽度时，"ensureLayout"是否以某种方式引用了它的先前计算，然后出现了舍入问题?

Any pointers where I might be missing something? Does 'ensureLayout' somehow refer to it's previous calculation and then have rounding issues when fitting the same string into its last-calculated width?

推荐答案

好的，关键是文本显示正确，但是视图大小错误.

OK, the key here was that the text was presented correctly but the size of the view was wrong.

我为NSTextView的layoutManager创建了一个delagate.在将NSTextView添加到NSOutlineView之后，文本被设置了3次(这似乎效率很低！).仅在前两个文本布局之后才在NSTextView上调用internalContentSize.

I created a delagate for the NSTextView's layoutManager. The text was being set out 3 times after the NSTextView was added to the NSOutlineView (which seems to be terribly inefficient!). intrinsicContentSize was only being called on the NSTextView after the first two text layouts.

从layoutManager内调用invalidateIntrinsicContentSize:didCompleteLayoutFor ...修复了所有问题.

Calling invalidateIntrinsicContentSize from within layoutManager: didCompleteLayoutFor... fixed everything up.

尽管如此，我仍然不明白这里发生了什么，以及为什么所有这些方法在展示内容时都会被多次调用.我想这与自动布局的复杂性和相互推things的事物有关.

I still don't understand what is happening here though, and why all these methods are being called so many times when stuff is presented. I guess it is to do with the complexity of auto layout and things pushing against each other.

我也不明白为什么在此过程中只有一些计算不正确.

I also don't understand why only some of the calculations were incorrect during the process.

如果有人可以对此有所启发，请在这里评论！

Please comment here if anyone can shine some light on this!

这篇关于NSOutlineView中的NSTextView的IntrinsicContentSize设置了错误的高度的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！