[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: NSComboBoxCell bug
Re: NSComboBoxCell bug
Fri, 12 May 2006 18:05:32 +0200
Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7.13) Gecko/20060411
great that you are going to look into this problem. I must admit that
even after your mail I don't quite understand, why the textDidChange:
call on the text object is needed here.
It really will help, if you find out what Cocoa is doing here.
Quentin Mathé wrote:
> Le 7 mai 06 à 21:58, Fred Kiefer a écrit :
>> Wolfgang Lux wrote:
>>> While this may fix your problem, I'd strongly advise against it.
>> Sorry, I already had hat fix applied, but if you are able to convince me
>> it does harm, I will take it out again.
> Hi Fred,
> I'm not sure about this one, I have to make some tests, but I think
> Wolgang is right on the fact this fix isn't correct.
>>> Calling textDidChange: in validateSelection *is* the right thing to do
>>> because the contents of the combo box did change after a user induced
>>> change (which is when textDidChange: should be called according to the
>>> docs). Other objects watching the contents of the combo box may in
>>> rely on the NSTextDidChangeNotification being sent.
>> Did you inspect the code that was changed? It is not about any code
>> directly on NSComboBoxCell, the validateSelection method is on the
>> GSComboWindow, this is a fairly internal class. Everything that goes no
>> here should only be of interest for the internal interaction of GNUstep.
>> Specificall the code where the textDidChange: call on the text object
>> (again not on the NSComboBoxCell) was removed has a FIXME around it, as
>> it should not be needed at all. At least Quentin thought so, when he
>> wrote the code.
> I added the following lines :
> // FIXME: Because NSCell doesn't behave correctly the line just
> over has
> // no effect, to correct this fact, the code below is needed.
> [textObject setString: [_cell _stringValueAtIndex:
> [_cell indexOfSelectedItem]]];
> * Dispatch the text notifications and by side effect update the
> * object value with the -textDidChange: method of NSTextField
> which is
> * the editor delegate
> [(NSTextView *)textObject didChangeText];
> // End of the code to remove
> to workaround the fact [_cell setStringValue: blabla] wasn't triggering
> textDidChange: notification as it should. When this method is entered,
> the cell is normally being edited with the field editor. In this
> precise case, the first problem was the field editor wasn't updated on
> -setStringValue: and by the way the textDidChange: notification wasn't
> sent on GNUstep (this doesn't match Cocoa behavior). Do you know
> whether this bug has been fixed ?
> I haven't fixed this bug when I worked on NSComboBoxCell and related,
> because it was tricky to implement and no core developers had a precise
> idea on how to do it iirc.
>> The interaction between the text object and the cell is again totally
>> internal, no other object should be watching for any notifications here.
>> All the notifications send by the NSComboBoxCell are hopefully
> That's not true. Even if no objects are watching most of the time, any
> objects can be potentially interested by field editor or cell
> notifications. _cell is the combobox cell precisely here. If the
> previous bug hasn't been fixed, NSComboBoxCell notifications are going
> to be affected, because in this precise case the textDidChange:
> notification is sent by the field editor (taking care of the combobox
> cell duty).
>>> The problem really is that NSComboBox's textDidChange: method should
>>> not perform text completion. Instead, text completion should only be
>>> performed when the user has entered text, so I think it would be more
>>> appropriate to override insertText: in NSComboBox and attempt text
>>> completion there.
>> The textDidChange: method is not on the control NSComboBox, but on the
>> cell class NSComboBoxCell.
> Wolfgang was probably referring to NSComboBoxCell here. Otherwise, I
> think what he suggests is probably the right solution (I'm unable to
> think of a bad side effect of -insertText: right now).
>> Please, don't get me wrong, I am not saying that the current code, or
>> more specifically the last change is fully correct.
> Noted :-).
>> If you see a
>> problem, please explain it or better, show it with some example code.
> Will know more on the issue after some tests.
> Quentin Mathé