Re: NSControl question

[Fred Kiefer]

Alexander Malmberg wrote:
> Andreas Hoeschler wrote: [snip]
>
> > In the class NSControl we have
> >
> > - (void) setObjectValue: (id)anObject { NSCell *selected = [self
> > selectedCell];
> >
> > [self abortEditing]; // <---------- what is this good for
> >
> > [selected setObjectValue: anObject]; if (![selected isKindOfClass:
> > actionCellClass]) [self setNeedsDisplay: YES]; }
> >
> > If I tab from one textField to another one then the second textField
> > after getting its editor gets a setObjectValue: by my control
> > association. This causes the editor to be removed again (--> bad).
> > Cocoa sees no nessecity to remove the editor in setObjectValue: After
> > removing this line on GNUstep my app worked as expected. However, I
> > am wondering whether this leads to any other problems.
> >
> > Any idea what this line is good for?
>
>
> If there's already a field editor and you change the value without
> doing anything else, the field editor will never learn about the new
> value; you'll still be displaying and editing the old value. Thus,
> just removing this call is definitely wrong (and indeed, these
> methods are explicitly documented to abort editing).
>
> We have similar issues keeping field editors up to date in other 
> situations, though, and I don't think simply aborting editing is the
>  best solution in all cases, so we probably need to do something. 
> Unfortunately, this is a messy part of GNUstep, and I'm not sure what
>  the right thing to do is (eg. in this case, it could simply be that
> some other method should be calling -set*Value: _before_ setting up
> the field editor). Cleaning up NSCell is on my TODO list, but it'll
> be a while before it's done. You might want to file a bug report for
> this in the mean time.

Aborting the editing is not that bad a solution either, so I don't see 
it as a bug. See what the Apple documentation says on this method:

"(void)setObjectValue:(id <NSCopying>)object
Sets the value of the receiver s cell (or selected cell) to object. If
the cell is being edited, it aborts all editing before setting the
value; if the cell doesn t inherit from NSActionCell, it marks the cell
s interior for automatic redisplay (NSActionCell performs its own
updating of cells)."

We could be a bit more selective on the editing status of the cell, that
is, only call abortEditing when this cell is the one being edited. But 
apart from this, we seem to follow the documentation very closely. So I 
am surprise that Apple is not doing it at all. If they diverge from the 
published specification, it may become hard to stay compatible with Cocoa.

Starting a cleanup of NSCell is a great idea. As this will break 
(forward) compatibility (new ivars, which also need to be stored in 
archives) with older GNUstep releases we should only start this after 
the new GUI release, which hopefully will come out this week.

Fred