Re: NSComboBoxCell bug

[Fred Kiefer]

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.

> 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 fact
> 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.
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 unaffected.

> 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.
Please, don't get me wrong, I am not saying that the current code, or
more specifically the last change is fully correct. If you see a
problem, please explain it or better, show it with some example code.

Cheers
Fred