On Wednesday, February 12, 2003, at 06:41 PM, Rich Morin wrote:
I suppose this works, but it's more work than it should be. It's much easier to connect actions to their targets in Interface Builder - that's what it's there for.# Set up a method to accept single-click events from Browser_F.
That's not what NSControlTextDidEndEditingNotification is intended for. It's not a notification that you should fire yourself. It's fired by the text field object, to notify interested observers that the *user* has edited - although not necessarily changed - the contents of the field.When a single click is detected by Browser_F, browserFSgl() picks up the path from Browser_F, sets the value of TextField_F, and posts a notification that TextField_F has finished editing:
There's nothing wrong with firing off your own notifications, of course; it's just that, if you want to do that, you should give them unique names that don't overlap those of notifications already in use.
You're receiving the notification before browserFSgl() gets called, because the notification is fired by the text field *automatically*, whenever an editing session finishes - regardless of whether the session resulting in changes being made to the text.When the notification arrives, controlTextDidEndEditing() picks up the new_path and compares it with the curr_path. It does this because it's getting called into action when I click on an item in Browser_F (before browserFSgl() gets called!).
Looking at your code, it's not apparent why you're calling controlTextDidEndEditing() (indirectly, via a notification) when the event you're responding to is, in fact, a click in on a browser cell. Those are two distinct events, and they should be handled as such - otherwise, as you've pointed out, the code starts looking rather peculiar.
It looks like what you want is two methods. One is an action method that's called in response to clicks on a browser cell, and the other is a delegate method that's called by the text field at the end of an editing session. In each method, the new path found in the object that generated the event needs to be supplied to the other object. Both of these methods are called directly by the GUI; neither should call the other.
Because you asked to be notified whenever the editing session ends - that doesn't always mean that the text has actually changed. If you want to be notified whenever the text has changed, you want to register to receive NSControlTextDidChangeNotification instead.# KLUDGE - why are we being called when nothing has changed?
Fair warning: If I recall correctly, this notification is fired for every single change - meaning for each character typed. That can be useful if it's what you really want; for example, you could provide live updates to the browser as the user is typing. But if all you want is to update the browser when the user is finished making changes, and either presses enter or moves to another control, it's less useful.
sherm--
"I have no special gift, I am only passionately curious." - Albert Einstein
