[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: NSControl question

From: Fred Kiefer
Subject: Re: NSControl question
Date: Thu, 23 Sep 2004 21:30:33 +0200
User-agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.6) Gecko/20040114

Alexander Malmberg wrote:
Andreas Hoeschler wrote: [snip]

In the class NSControl we have

- (void) setObjectValue: (id)anObject { NSCell *selected = [self

[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.


reply via email to

[Prev in Thread] Current Thread [Next in Thread]