Основные данные: Странная ошибка привязки на повторном открытии документа. Помогите?

голоса
2

Я создание приложения данных ядра администрировать некоторые данные, и я был озадачен ошибкой, что указывает на мои объекты не Кво требованиям. Тем не менее, я не изменял КВО по умолчанию соответствия NSManagedObject на, и теперь я оставил чесать голова.

Область применения, что ошибка затрагивает в том, чтобы создать некоторые категории и организации некоторых элементов, которые будут жить внутри этих категорий. Элементы могут существовать в нескольких категориях и элементы и категории просмотра порядок может быть установлен пользователем. Простые вещи.

Чтобы лучше представить себе это, основные части модели данных ядра я настройки отображаются ниже. Я упростил имена и атрибуты сущностей несколько:

Category <--------->> CategoryItem <<---------> Item
--------              ------------              --------
name                  viewPosition              name
viewPosition                                    description

Эта модель связана с двумя ArrayControllers в Interface Builder, один для категорий и один для categoryitems. Categoryitems набор содержимого устанавливается в контроллер категории массива с помощью selection.categoryItems связывания. Эти контроллеры массива питаются два вида таблицы. Содержание таблицы категорий предметов привязан к контроллеру CategoryItem переменного тока через arrangedObjects.item.name.

Это все работает отлично, и я перетаскиванием и заказ как товары и категории в моих сердцах желание.

для одного странного случая исключения.

Всякий раз, когда я создаю категорию с точно один элемент, а затем сохранить, если я затем повторно открыть документ, представленный я со следующей ошибкой:

Невозможно удалить наблюдатель <NSTableBinder 0x1627f670>для ключевого пути «item.name» из <NSManagedObject 0x16273380>, скорее всего потому , что значение ключа «элемент» изменилось без соответствующего уведомления KVO отправки. Проверьте Кво-соответствие класса NSManagedObject.

После того, что интерфейс кажется разваливаться и приложение становится непригодным для использования. Я искал в Интернете, и все, что я могу раскрыть, что это указывает на КВЦ несоблюдения. Но я использую стандартные, едва измененную, классы Apple, здесь.

Ошибка не поднимается, когда я связываю с viewPosition лишь в CategoryItem. т.е. через arrangedObjects.viewPosition вместо arrangedObjects.item.name. Это как если бы отношения между categoryitem и пунктом не готовы в точке таблица первоначально наблюдает (и только если есть один пункт).

кто-нибудь еще сталкивался с этим? Можно ли думать о возможном обходного пути?

Задан 22/06/2009 в 19:22
источник пользователем
На других языках...                            


3 ответов

голоса
2

Оказалось, что это будет ошибкой. Вот отчет, с указанием причины и обходной путь.

«Авто содержания Перестановки» NSArrayController вызывает исключение КВО для NSManagedObjects

Краткое описание: Когда «Auto Перестановка Content» проверяются на NSArrayController, управляющие данными в сущности основных данных, исключение «Не удается удалить наблюдатель для ключевого пути„х“», поднимаются.

Из моего исследования, кажется, как будто, что, когда «содержание Перестановка авто» проверяется на соответствие NSArrayController, КВО не полностью достигнута. По большей части, это работает отлично, но есть один конкретный случай, который я нашел, что нарушает это соответствие.

Это трудно сформулировать, но это, кажется, происходит при попытке доступа отношения (т.е. arrangedObjects.person.name) в сущности управляемых с помощью NSArrayController с автоматическим переставить содержание проверено. В дополнении к этому, кажется, происходят после повторного открытия документа и когда контроллер управляет набором ровно один пункта только ...

Это, наверное, проще, если посмотреть пример проекта и выполните следующие шаги ...

Шаги для воспроизведения: 1) Откройте проект прилагается 2) Откройте MyDocument.xib 3) Проверьте, что "Auto Перестановка Контент проверяется на« деятельность лиц NSArrayController 4) Создание и идти 5) Добавить одну активность, нажав на плюс ниже левый столбец 6) Добавить одну активность Person (не больше, не меньше), нажав на плюс ниже в правой колонке 7) Сохранить документ 8) Повторно откройте документ

Ожидаемые результаты: Документ открыт, и пользователь имеет возможность добавлять и удалять деятельности и лиц, по желанию с отзывчивым интерфейсом.

Фактические результаты: UI ведет себя непредсказуемо, как только правая колонка пытается отобразить активность пропавшие в деятельности только с одним активностью Person. Оказывает приложение непригодным для использования.

Примечания: Я создал тестовый проект, чтобы найти эту ошибку, код и модель должны быть предельно понятны, но не стесняйтесь обращаться ко мне с любыми вопросами.

Эта проблема может быть разработана вокруг отключив Auto переставить Содержание и вызов arrangeObjects на NSArrayController вручную.

Ответил 03/12/2009 в 18:43
источник пользователем

голоса
1

После долгих головы почесывания и ноги тиснения я, наконец, решить эту проблему. Woohoo!

Причина этого вопроса на самом деле оказалась экземпляр NSNumberFormatter я зарыл в одном из моих взглядов таблицы. Я должен был уделить больше внимания к сообщению консоли я получал от Interface Builder.

23/06/2009 15:05:08 ibtool[2324] -[NSConcreteAttributedString initWithString:] called with
nil string argument. This has undefined behavior and will raise an exception in post-
Leopard linked apps. This warning is displayed only once.

То, что это на самом деле оказалось, значит, что мой NSNumberFormatter не было это нулевой символ и Nil Набор символов (конфигурация по умолчанию). Установка этих обоих к нулю удалены выше ошибки, а затем, как по волшебству, я был еще раз KVO требованиям.

Я подсчитал, что это может быть причиной выше сообщение консоли из следующего поста: http://www.cocoabuilder.com/archive/message/cocoa/2009/5/28/237646

Сообщение было беспокоить меня, но, как кажется, не влияет на мое заявление, и был сгенерирован «ibtool» (т.е. не мое приложение), я решил проигнорировать его изначально. В основном потому, что я не имел ни малейшего представления о том, где я хотел бы найти виновника, вызвавший предупреждение. Это не было, пока я не гуглом сообщения консоли я был в состоянии решить. Я предполагаю, что я все еще многому научиться в мире отладки какао!

То, что я до сих пор находят странным является то, что она затронула только вновь открытые документы ровно один элемент в категории ...

Ответил 23/06/2009 в 16:25
источник пользователем

голоса
0

Невозможно удалить наблюдатель <NSTableBinder 0x1627f670>для ключевого пути «item.name» из <NSManagedObject 0x16273380>, скорее всего потому , что значение ключа «элемент» изменилось без соответствующего уведомления KVO отправки. Проверьте Кво-соответствие класса NSManagedObject.

Это, на самом деле, наиболее вероятное объяснение. Вы изменили значение, не отправляя уведомление КВО.

Вы, вероятно, делать что-то вроде этого:

[item release];
item = [newItem retain];

Это не верно. Прямой экземпляр присваивание переменное не отправляет уведомление Кво, так что это заявление не говорит о других объектах изменения.

Вам нужно пройти через ваши аксессор, вместо этого. Одним из способов являются явным сообщением аксессора:

[self setItem:newItem];

Другой способ присвоения собственности:

self.item = newItem;

Они оба эквивалентны и дают те же результаты, которые включают в себя уведомление КВО.

Обратите внимание , что оба правильных решений не включать retainили copyсообщение. Это работа вашего сеттер аксессора (синтезировать ли вы, пусть основные данные создавать динамически, или написать его самостоятельно).

Главное исключение из этого правила всегда потребительная Accessors, что вы всегда должны делать прямой экземпляр переменного назначения (с соответствующими releaseи retain/ copyсообщениями) , в initметодах и deallocметоде. В противном случае, вы посылаете сообщения в пол-inited / -deallocked объекта.

Ответил 22/06/2009 в 23:45
источник пользователем

Cookies help us deliver our services. By using our services, you agree to our use of cookies. Learn more