You're quite right. I finally had time to look into this, and agree that my earlier fix inadvertently introduced a bug when editing is ended by clicking on another control. I've just checked in a new change (r29056) that fixes this in our testplant branch. Hopefully someone can migrate this fix into the trunk soon.
Regards,
Doug
| -- Doug Simons Principal Developer | ||||||||
| | ||||||||
| ||||||||
| http://www.testplant.com | ||||||||
| | ||||||||
| This email and any attachments may contain privileged / confidential information. If you have received this email in error or believe that you are not the intended recipient, please delete all content and attached files and contact TestPlant via the switchboard on +1 720-890-0211 or via return e-mail. You should not copy, forward or use any part of the contents in any way. Any such unauthorised use or disclosure may be unlawful. |
On Nov 20, 2009, at 8:37 AM, Wolfgang Lux wrote:
Hi Doug,
I'm having a little problem with this patch, which made it to the trunk meanwhile thanks to Fred. The change in NSTextField's -textDidEndEditing: ensures that the text field always sends its action when editing ends and the text field is configured that way, which I think is correct. However, with your patch the text field also sends -selectText: to itself when it is first responder. This is definitely wrong in at least one case: The -textDidEndEditing: callback is called when the text field resigns first responder because the user clicked into another view. At the time when -textDidEndEditing: is called the text field is still first responder and so will incorrectly call -selectText:. Therefore I'd prefer to revert this part of your change and call -selectText: only when editing ends with either NSTabTextMovement or NSBacktabTextMovement (as before) unless your change is supposed to fix a bug in GNUstep.
Wolfgang