Re: mark added object in NSArrayController as "dirty"?

FROM : Quincey Morris
DATE : Fri Aug 29 01:49:04 2008

On Aug 28, 2008, at 10:37, Matt Neuburg wrote:

> Thanks (and your answer was extremely useful and confirmed my own 
> further
> experiments), but the problem is that I'm not even getting that. 
> That would
> be a reduced version of what I'd like to do, i.e. it would help me 
> if I
> could just fool the system into thinking that the user has edited 
> any field
> at all. Being *in* a field is not enough to do this; you have to 
> *change*
> the field. But I need to do this in a way that makes the system 
> think the
> *user* changed the field...


FWIW, here's an alternative point of view on your problem:

First, the reason this is causing you difficulty is that you've 
*already* inserted an "invalid" object into your data model before the 
user starts filling in the fields. It's a little unreasonable to 
expect the user interface to validate your data model after the fact, 
when the standard behavior is intended to prevent invalid data getting 
into the model in the first place.

Second, preventing the user from moving on without filling in the 
fields of the "invalid" object is modal in a way that the best Mac 
applications aren't modal. Perhaps the user might want to refer to an 
existing object before completing the new one. How about you forget 
about trying to force the user to fill in the fields initially, but 
verify the data model programatically at the point(s) where you 
actually go to use the data? At that point you could re-display the 
invalid object, and tell the user to fill it in or delete it. Or just 
delete it automatically.

If the insertion *must* be modal, it might be better to be explicit 
about it: instead of creating an invalid object when the Add button is 
clicked, display a sheet that has fields for the required object 
properties, and create the object after the sheet data is validated 
and OKed.

Of course, this is said knowing nothing about the application, but 
considering a different solution might give something better-defined 
to implement and, as a bonus, more convenient for users.

Feel free to ignore this if I'm off base here.