7

мне интересно, как можно было бы реализовать режим структуры, как одной Xcode 3 использует для конфигурации сборки:Реализация NSOutlineView/NSTableView с различными клетками (и типов данных) в строке

alt text http://img812.imageshack.us/img812/9467/xcodeoutlineview.png

При используя NSOutlineView/NSTableView со связями и NSTreeController/NSArrayController, столбцы представления получают привязки, назначенные, а не отдельные ячейки по очевидным причинам. Если каждая строка в столбце использует одну и ту же ячейку, то это кусок торта. Однако если каждая строка (потенциально) использует свой собственный тип ячейки (и с этой потенциально собственной коллекцией привязок), тогда все становится фанки.

Глядя на скриншот, можно ясно видеть, что ячейке текстового поля требуется только одно связывание для «значения». В то время как необходимо всплывающую кнопку ячейки по меньшей мере, один для «содержания», один для «contentValues ​​» и последний, но не менее одного связывания для «SelectedIndex/selectedObject/SelectedValue». И клетке флажка нужна привязка для «значение» и (возможно) одна для «title».

Как можно сделать это с чистым (и маленьким) кодом, насколько это возможно?
(Или как можно было бы спросить:Как бы Apple, сделала это?)

...

Вот что я пробовал себя до сих пор:
я предоставить соответствующую (скопированную) клетку через [outlineView: dataCellForTableColumn: item:] и привязать их к отдельным моделям данных (из [item createdObject]). Я знаю точное количество данных (< 500 строк), отображаемых в виде контура, поэтому наличие одной ячейки в строке не должно быть слишком большой проблемой памяти, нет? Я получил данные для правильного отображения через привязки (yay!), Однако я не могу изменить ни одно из их значений. O_o Очевидно, изменение стоимости просто не доходит до модели данных. Это больше, чем простой [checkboxCell bind: @ "value" toObject: rowModel withKeyPath: @ "value" options: nil]? (Как это кажется достаточно для получать значения, но не для установки их соответствующим образом.)

Я не мог найти любую информацию по этой теме. Много информации и подсказок для использования пользовательских ячеек для каждого столбца, но не для их использования по принципу «для каждой строки». :(
Это сделало бы замечательный материал для учебника по какао, не так ли?;)

+0

Существует также NSDictionaryController. Не знаю, как далеко это приведет тебя к этому, но посмотри. –

+0

@Mike Это не столько проблема контроллера, сколько один вид таблицы, обрабатывающий его ячейки. Но спасибо в любом случае :) – Regexident

+0

почти 5 лет спустя, и это была единственная информация, которую я смог найти о смешивании привязок с источником данных в таблице с разными ячейками: «Это создаст отличный материал для учебника Cocoa, не так ли?» , черт возьми! – rraallvv

ответ

3

Ячейка данных столбца не копируется. Ячейка настроена для правильного значения столбца в каждой строке и нарисована в нужном месте. Хорошее место для подключения - метод NSTableColumn -dataCellForRow:. В пользовательском подклассе вы можете переопределить этот метод и передать либо его -dataCell для нормальной работы, либо какой-либо альтернативный тип ячейки.

У меня был случай иметь столбец флажка, представляющий «включить» в виде схемы, который появился только для детей (элементы, отличные от корней). Корневые элементы не могут быть исключены, только их дети, поэтому имеет смысл только показать флажок для элементов, отличных от root.

Я создал пользовательский подкласс NSTableColumn, который взял делегат (мой контроллер источника данных) и проверил, ответил ли он на селектор -deadCellColumn: shouldShowDeadCellForRow :. Если это так, я назвал этот метод (который был реализован на моем контроллере источника данных), чтобы спросить его, должен ли я показывать «мертвую ячейку» (базовый подкласс NSCell, который ничего не рисует) и поменял ее в соответствии с ответом. Если делегат не ответил на селектор, столбец таблицы возвращает свой normal-dataCell.

Здесь была нужна специальная ячейка (которую я назвала «DeadCell»), потому что я хотел, чтобы ничто не было нарисовано, и ничего не редактировалось. Я не уверен, что это было строго необходимо, но я все равно это сделал. Это не очень полезно в вашем случае, но я хотел бы заявить об этом в любом случае для полноты.

Ваша ситуация немного сложнее, особенно потому, что задействованы привязки (а разные типы ячеек данных могут иметь разные привязки для их значения - всплывающие окна могут быть особенно сложными). В моем случае я отказался от привязки для проверенного механизма источника данных. Это очень упростило ситуацию. :-) Для вашего случая достаточно легко менять типы ячеек с использованием методов источника данных.

+0

Ой, мой ... Полагаю, мне придется «объединить» свои данные, затем (используя ComboBoxCells для легкого доступа к значениям шаблона) и использовать NSFormatters для обеспечения правильного ввода для типа значений каждого элемента. Не очень, но функция, которая требует такого вида таблиц, просто невелика/важна, чтобы вложить такой огромный код и, возможно, взломать. Большой облом, хотя такой материал - такой беспорядок, с которым можно работать. – Regexident

+0

В этом нет никакого хакерства. Это все допустимое использование механизма управления/ячейки. Кроме того, привязки какао больше подходят для «быстрого развития приложений», что только исключает код для более обобщенных случаев. Если вы хотите делать что-то особенное, вам нужно использовать код. Во многих ситуациях вы можете смешивать два (привязки и источник данных). В этой ситуации, если у ваших типов ячеек все одинаковые привязки, вам нужен только ваш собственный столбец, а все остальное должно «просто работать». –

+0

Да, но они ** не ** имеют одинаковые привязки :( И в любом случае эта функция будет более увлекательной, с очень ограниченной потенциальной пользовательской базой, поэтому просто не стоит таких чрезмерных усилий при отсрочке выпуска продукта: («отличное судно разработчиков», правильно?;) Но спасибо за решение. Я уверен, что я буду использовать его не слишком далеко. – Regexident

 Смежные вопросы

  • Нет связанных вопросов^_^