NSTableView*
Changing selection within the tableview should not be allowed
if
it is
not firstResponder or if a cell being edited contains an
invalid
string.
- (void)mouseDown:(NSEvent *)theEvent
{
...
/* Stop editing if any */
if (_textObject != nil)
{
if (_editedCell != nil && [_editedCell
isEntryAcceptable:[_textObject
text]] == NO)
{
NSBeep();
return;
}
[self validateEditing];
[self abortEditing];
}
I can see some reason for this change, but somehow this seems to
be the
wrong place for it. Or we will need a similar change in plenty of
places
in NSTableView.
Let me know if you find a better one. :-)
Not sure, but perhaps it is better to just remove the whole check and
let the resignFirstResponder on the text editor, a few lines below take
care of validating the previous editing?
My feeling is that we are handling the whole process of editing way to
complicated. The have to be clear rules to stick to and then all this
special case handling should not be needed. We just have to find the
rules.
if ([[self window] firstResponder] != self)
{
NSBeep();
return;
}
Why this? How would a table view ever become the first responder
if we
are not allowed to click on it?
The tableview is not made first responder in NSTableView mouseDown, at
least my tableview gets first responder fine even with this patch
applied. However, consider the case I mentioned in my other mail, an
NSTextField with a formatter below the tableview with an invalid
string.
This textfield is firstResponder and it will resign to give up first
responder since the string is invalid. Without this patch the user
could
click on any row in the tableview a change its selection. This must be
prevented!
What about checking in NSWindow sendEvent: if the view could be made
first responder and only passing on the mouse down event if that was
successful?
This could have unexpected results for views that work with the mouse
without becoming first responder. Does any such view exist?
*NSTextField*
This fix makes sure, that objectValue is valid, when the
delegate method
is called (which is the case on MacOSX).
- (BOOL)textView:(NSTextView *)textView
doCommandBySelector:(SEL)command
{
if (sel_eq (command, @selector(insertNewline:)))
{
[self validateEditing];
}
if (_delegate && [_delegate respondsToSelector:
@selector(control:textView:doCommandBySelector:)])
{
return [_delegate control:self textView:textView
doCommandBySelector:command];
}
return NO;
}
I need more explanation for this change. It looks wrong to me.
The user enters a date into a texfield with a date formatter and
presses
return to trigger a fetch operation. A way (may be no nice one but
anyway) to implement that in the controller class would be to make the
controller delegate of the textfield and implement -control: textView:
doCommandBySelector: to call fetch which access the textfield via an
outlet, this gets the date and generates SQL...
Without my patch, [textfield objectValue] will return nil. :-( On
MacOSX
it does return the validated date.
Yes, but where does the validation happen? My last question, the one
you
deleted, was if this may happen inside the objectValue method itself.
MacOSX has to call validateEditing somewhere, but where?