discuss-gnustep
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: gui fixes


From: Fred Kiefer
Subject: Re: gui fixes
Date: Fri, 31 Aug 2007 10:41:52 +0200
User-agent: Thunderbird 1.5.0.12 (X11/20060911)

Andreas Höschler wrote:
>         *
>         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?


>         Check whether delegate does implement didFailToFormatString: and
>         accept
>         empty string.
>         - (void)validateEditing
>         {
>         if (_text_object)
>         {
>         NSFormatter *formatter = [_cell formatter];
>         NSString *string = AUTORELEASE ([[_text_object text] copy]);
>         id newObjectValue = string;
>         BOOL validatedOK = YES;
> 
>         if (formatter != nil)
>         {
>         NSString *error;
> 
>         validatedOK = [formatter getObjectValue:&newObjectValue
>         forString:string
>         errorDescription:&error];
> 
>         if (!validatedOK)
>         {
>         newObjectValue = nil;
> 
>         if ([_delegate
>         
> respondsToSelector:@selector(control:didFailToFormatString:errorDescription:)])
> 
> 
>         {
>         validatedOK = [_delegate control:self didFailToFormatString:string
>         errorDescription:error];
>         }
>         else if ([string isEqualToString:@""])
>         {
>         validatedOK = YES;
>         }
>         }
>         }
> 
>         if (validatedOK)
>         {
>         [_cell setObjectValue:newObjectValue];
>         }
>         }
>         }
> 
> 
>     This changes some calls from setStringValue: into setObjectValue:, I am
>     not sure this is what we want.
> 
> 
> if (validatedOK)
> {
> if (formatter) [_cell setObjectValue:newObjectValue];
> else [_cell setStringValue:newObjectValue];
> }
> 
> Better?
> 

Looks closer to the original code. I am not sure if that was correct, at
least nobody complained :-)




reply via email to

[Prev in Thread] Current Thread [Next in Thread]