Re: NSControl question

[Andreas Hoeschler]

On Donnerstag, September 23, 2004, at 09:30  Uhr, Fred Kiefer wrote:

> > > 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)."

Interesting! I observed a different behaviour on MacOSX. However, I get 
the point. I modified my association so that it checks the current 
objectValue and only invokes setObjectValue: if the value to be set is 
different. This works around my problem without removing the 
abortEditing line in setObjectValue. It's cumbersome. Would it be 
feasable to bring this functionality to setObjectValue:. I guess Coca 
only removes the editor, if setObjectValue: actually changes the 
objectValue, not if the same objectValue is reapplied.

Regards,

  Andreas