Table Data and NSArrayController
-
I have a table whose data is gotten from an NSArrayController. The
NSArrayController gets its arranged data from the default user
preferences controller, which finds an array of strings. This works
perfectly, as the table shows the list of strings stored in the
preferences plist. However, when I try to edit the string in the table,
my changes take absolutely no effect, and the data reverts to what was
retrieved from the plist at first. I even tried changing the preference
file during execution, but those changes were overwritten, so the
preferences are not being updated. More strangely, I can add other
entries by means of a button whose target is the add: method of the
NSArrayController, but I can only add entries without content. That is,
empty entries are added to the table and to the preferences file, but
then I have the same problem with editing those new entries as I did
with the first entries. In short, how can I make this work? How can I
have a table to which you can entries and have them written to file via
the controllers and so on. Thanks.
_______________________________________________
cocoa-dev mailing list | <cocoa-dev...>
Help/Unsubscribe/Archives: http://www.lists.apple.com/mailman/listinfo/cocoa-dev
Do not post admin requests to the list. They will be ignored. -
Yep... here's the problem.
You've got a NSMutableArray that you're storing the array of strings
in. This array is written to the user defaults.
When you read the array from user defaults, you are not getting a
mutable array, you're getting an immutable array. So, when you try to
make changes, you get hosed.
You either need to convert that data to a mutable array through a value
transformer, or write the data out using the value transformer
NSUnarchivedData. The first would be better in defaults as it would be
easily editable, but would require you to write the transformer (not
that it would be a huge effort). The second would require no coding,
but you're defaults get more obscured in the file (which may not be a
bad thing)
On Dec 23, 2003, at 5:21 PM, <lingwitt...> wrote:
> I have a table whose data is gotten from an NSArrayController. The
> NSArrayController gets its arranged data from the default user
> preferences controller, which finds an array of strings. This works
> perfectly, as the table shows the list of strings stored in the
> preferences plist. However, when I try to edit the string in the
> table, my changes take absolutely no effect, and the data reverts to
> what was retrieved from the plist at first. I even tried changing the
> preference file during execution, but those changes were overwritten,
> so the preferences are not being updated.
[demime 0.98b removed an attachment of type application/pkcs7-signature which had a name of smime.p7s]
_______________________________________________
cocoa-dev mailing list | <cocoa-dev...>
Help/Unsubscribe/Archives: http://www.lists.apple.com/mailman/listinfo/cocoa-dev
Do not post admin requests to the list. They will be ignored. -
Thanks for the reply,
I don't think that this is the case, or at least the whole case. I can
still add anything to the NSArrayController. I overrode the add: method
with:
- (void)add: (NSObject*)sender
{
[self addObject: @"Hello"];
}
which successfully adds a Hello to the table and to the preferences. I
think the problem is that the content of the NSStrings (that's the
data) cannot be modified. I decided to then encapsulate the NSStrings,
making them a variable in a class, so that a more proper binding path
could be made with keys in interface builder rather than dealing
directly with objects, but these classes can't be written to file, so I
made a transformer that simply takes an array of strings and converts
it to an array of string encapsulators and vice versa: The code is as
follows:
- (id)transformedValue:(id)value
{
NSLog([value description]);
if ([value isKindOfClass: [NSString class]])
return [Encapsulator encapsulatorWithString: value];
else if ([value isKindOfClass: [NSArray class]])
{
NSMutableArray* array = [NSMutableArray array];
NSEnumerator* valueEnumerator = [value objectEnumerator];
while (NSString* valueString = [valueEnumerator nextObject])
{
[array addObject: [Encapsulator encapsulatorWithString:
valueString]];
return array;
}
}
return nil;
}
However, nothing is done because the value is of type:
_NSControllerObjectProxy
What am I to do? For every great thing that you can do with the
controller layer, there are two extremely annoying inhibitors.
On 23 Dec 2003, at 6:07 PM, Scott Anguish wrote:
> Yep... here's the problem._______________________________________________
>
> You've got a NSMutableArray that you're storing the array of strings
> in. This array is written to the user defaults.
>
> When you read the array from user defaults, you are not getting a
> mutable array, you're getting an immutable array. So, when you try to
> make changes, you get hosed.
>
> You either need to convert that data to a mutable array through a
> value transformer, or write the data out using the value transformer
> NSUnarchivedData. The first would be better in defaults as it would
> be easily editable, but would require you to write the transformer
> (not that it would be a huge effort). The second would require no
> coding, but you're defaults get more obscured in the file (which may
> not be a bad thing)
cocoa-dev mailing list | <cocoa-dev...>
Help/Unsubscribe/Archives: http://www.lists.apple.com/mailman/listinfo/cocoa-dev
Do not post admin requests to the list. They will be ignored. -
you're correct - it's not the whole story, mmalc reminded me that there
are issues with trying to use NSString's in an array directly. Try
instead putting them into an NSDictionary, and add each NSDictionary to
the array.
it adds little extra effort (declare NSMutableDictionary as the type
for the NSArrayController - use a named key to refer to the object, so
selected.theKey), and obfuscates the defaults a bit)
On Dec 24, 2003, at 12:28 AM, <lingwitt...> wrote:
> I don't think that this is the case, or at least the whole case. I can
> still add anything to the NSArrayController. I overrode the add: method
> with:
>
> - (void)add: (NSObject*)sender
> {
> [self addObject: @"Hello"];
> }
[demime 0.98b removed an attachment of type application/pkcs7-signature which had a name of smime.p7s]
_______________________________________________
cocoa-dev mailing list | <cocoa-dev...>
Help/Unsubscribe/Archives: http://www.lists.apple.com/mailman/listinfo/cocoa-dev
Do not post admin requests to the list. They will be ignored. -
I still need to transform the immutable to the mutable dictionary, so
how do I do this since I have to deal with an undocumented private
class?
On 24 Dec 2003, at 12:48 AM, Scott Anguish wrote:
> it adds little extra effort (declare NSMutableDictionary as the type_______________________________________________
> for the NSArrayController - use a named key to refer to the object, so
> selected.theKey), and obfuscates the defaults a bit)
cocoa-dev mailing list | <cocoa-dev...>
Help/Unsubscribe/Archives: http://www.lists.apple.com/mailman/listinfo/cocoa-dev
Do not post admin requests to the list. They will be ignored. -
What happens is that setValue:withKey: gets called on the strings with
a key of @"". KVC magic will eventually look for a selector of
"set<Key>:", so the easiest solution is this:
@implementation NSMutableString (MyStringAdditions)
- (void)set:(id)value { [self setString:value]; }
@end
Just make sure the controller is set to manage object class
NSMutableString and everything works great.
On Dec 23, 2003, at 11:48 PM, Scott Anguish wrote:
> you're correct - it's not the whole story, mmalc reminded me that there
> are issues with trying to use NSString's in an array directly. Try
> instead putting them into an NSDictionary, and add each NSDictionary to
> the array.
>
> it adds little extra effort (declare NSMutableDictionary as the type
> for the NSArrayController - use a named key to refer to the object, so
> selected.theKey), and obfuscates the defaults a bit)
>
>
>
> On Dec 24, 2003, at 12:28 AM, <lingwitt...> wrote:
>
>> I don't think that this is the case, or at least the whole case. I can
>> still add anything to the NSArrayController. I overrode the add:
>> method
>> with:
>>
>> - (void)add: (NSObject*)sender
>> {
>> [self addObject: @"Hello"];
>> }
>
> [demime 0.98b removed an attachment of type
> application/pkcs7-signature which had a name of smime.p7s]
> _______________________________________________
> cocoa-dev mailing list | <cocoa-dev...>
> Help/Unsubscribe/Archives:
> http://www.lists.apple.com/mailman/listinfo/cocoa-dev
> Do not post admin requests to the list. They will be ignored.
[demime 0.98b removed an attachment of type application/pkcs7-signature which had a name of smime.p7s]
_______________________________________________
cocoa-dev mailing list | <cocoa-dev...>
Help/Unsubscribe/Archives: http://www.lists.apple.com/mailman/listinfo/cocoa-dev
Do not post admin requests to the list. They will be ignored. -
On Dec 24, 2003, at 3:39 PM, <lingwitt...> wrote:
> I still need to transform the immutable to the mutable dictionary, so
> how do I do this since I have to deal with an undocumented private
> class?
>
how is NSValueTransformer an undocumented class?
or, are you thinking of some other class?
[demime 0.98b removed an attachment of type application/pkcs7-signature which had a name of smime.p7s]
_______________________________________________
cocoa-dev mailing list | <cocoa-dev...>
Help/Unsubscribe/Archives: http://www.lists.apple.com/mailman/listinfo/cocoa-dev
Do not post admin requests to the list. They will be ignored. -
I'm not sure that you can count on this behavior working long term.
This sounds like a bug/loophole, and I'd not count on it working in
production code.
On Dec 24, 2003, at 6:55 PM, Daryn wrote:
> What happens is that setValue:withKey: gets called on the strings with
> a key of @"". KVC magic will eventually look for a selector of
> "set<Key>:", so the easiest solution is this:
>
> @implementation NSMutableString (MyStringAdditions)
>
> - (void)set:(id)value { [self setString:value]; }
>
> @end
>
> Just make sure the controller is set to manage object class
> NSMutableString and everything works great.
>
> On Dec 23, 2003, at 11:48 PM, Scott Anguish wrote:
>
>> you're correct - it's not the whole story, mmalc reminded me that
>> there
>> are issues with trying to use NSString's in an array directly. Try
>> instead putting them into an NSDictionary, and add each NSDictionary
>> to
>> the array.
>>
>> it adds little extra effort (declare NSMutableDictionary as the type
>> for the NSArrayController - use a named key to refer to the object, so
>> selected.theKey), and obfuscates the defaults a bit)
>>
>>
>>
>> On Dec 24, 2003, at 12:28 AM, <lingwitt...> wrote:
>>
>>> I don't think that this is the case, or at least the whole case. I
>>> can
>>> still add anything to the NSArrayController. I overrode the add:
>>> method
>>> with:
>>>
>>> - (void)add: (NSObject*)sender
>>> {
>>> [self addObject: @"Hello"];
>>> }
>>
>> [demime 0.98b removed an attachment of type
>> application/pkcs7-signature which had a name of smime.p7s]
>> _______________________________________________
>> cocoa-dev mailing list | <cocoa-dev...>
>> Help/Unsubscribe/Archives:
>> http://www.lists.apple.com/mailman/listinfo/cocoa-dev
>> Do not post admin requests to the list. They will be ignored.
>
> [demime 0.98b removed an attachment of type
> application/pkcs7-signature which had a name of smime.p7s]
> _______________________________________________
> cocoa-dev mailing list | <cocoa-dev...>
> Help/Unsubscribe/Archives:
> http://www.lists.apple.com/mailman/listinfo/cocoa-dev
> Do not post admin requests to the list. They will be ignored.
[demime 0.98b removed an attachment of type application/pkcs7-signature which had a name of smime.p7s]
_______________________________________________
cocoa-dev mailing list | <cocoa-dev...>
Help/Unsubscribe/Archives: http://www.lists.apple.com/mailman/listinfo/cocoa-dev
Do not post admin requests to the list. They will be ignored. -
I clarified this in another email that got lost, but the gist is that
the value transformer is given an undocumented private class from the
controller layer. This doesn't matter any more though, because I fixed
the problem by simply loading in the defaults my self, making them the
proper type and then adding them to to the array controller. Thanks for
all of your help. If you can tell me how to get around these private
classes though, it would be appreciated.
On 25 Dec 2003, at 1:35 AM, Scott Anguish wrote:
> how is NSValueTransformer an undocumented class?_______________________________________________
>
> or, are you thinking of some other class?
cocoa-dev mailing list | <cocoa-dev...>
Help/Unsubscribe/Archives: http://www.lists.apple.com/mailman/listinfo/cocoa-dev
Do not post admin requests to the list. They will be ignored. -
I explained this in another email that got lost. The transformer is
passed an object that is an undocumented private class, so it makes
conversion difficult. How should that be dealt with?
This is not of great concern any longer, because I fixed the problem by
loading the defaults and saving them by hand.
On 25 Dec 2003, at 1:35 AM, Scott Anguish wrote:
> how is NSValueTransformer an undocumented class?_______________________________________________
>
> or, are you thinking of some other class?
cocoa-dev mailing list | <cocoa-dev...>
Help/Unsubscribe/Archives: http://www.lists.apple.com/mailman/listinfo/cocoa-dev
Do not post admin requests to the list. They will be ignored. -
On Dec 25, 2003, at 9:56 AM, <lingwitt...> wrote:
> I clarified this in another email that got lost, but the gist is thatIt's not clear what you have to "get around"?
> the value transformer is given an undocumented private class from the
> controller layer. This doesn't matter any more though, because I fixed
> the problem by simply loading in the defaults my self, making them the
> proper type and then adding them to to the array controller. Thanks
> for all of your help. If you can tell me how to get around these
> private classes though, it would be appreciated.
>
When are you given a private class, and what can you not do with it
that you cannot do with the object you were expecting?
mmalc
_______________________________________________
cocoa-dev mailing list | <cocoa-dev...>
Help/Unsubscribe/Archives: http://www.lists.apple.com/mailman/listinfo/cocoa-dev
Do not post admin requests to the list. They will be ignored. -
The arranged objects are returned as a proxy of sorts. I think that
this can be gotten around by using content as the key. Thanks anyway
and sorry for the confusion.
On 25 Dec 2003, at 3:38 PM, mmalcolm crawford wrote:
> It's not clear what you have to "get around"?_______________________________________________
> When are you given a private class, and what can you not do with it
> that you cannot do with the object you were expecting?
cocoa-dev mailing list | <cocoa-dev...>
Help/Unsubscribe/Archives: http://www.lists.apple.com/mailman/listinfo/cocoa-dev
Do not post admin requests to the list. They will be ignored.
