On Wednesday, December 12, 2007, at 10:19AM, "Christiaan Hofman" <[EMAIL
PROTECTED]> wrote:
>
>On 12 Dec 2007, at 6:17 PM, Adam R. Maxwell wrote:
>
>>
>> On Dec 12, 2007, at 2:59 AM, Christiaan Hofman wrote:
>>
>>>
>>>
>>> On Dec 12, 2007 6:38 AM, Adam R. Maxwell <[EMAIL PROTECTED]> wrote:
>>>
>>> On Dec 11, 2007, at 12:39 PM, Christiaan Hofman wrote:
>>>
>>>>
>>>> On 11 Dec 2007, at 9:30 PM, Adam R. Maxwell wrote:
>>>>
>>>>> Is there any way we can get rid of the finalize changes stuff or
>>>>> endEditingFor:? I think we're bypassing NSDocument and the
>>>>> formatters in some cases, because of legacy behavior. I'm thinking
>>>>> of -[BibEditor windowShouldClose:] in particular, but
>>>>> forceEndEditing is another tricky part to handle correctly.
>>>>>
>>>>
>>>> I don't think so. Without binding, I think explicitly ending editing
>>>> is the only way to commit. Why do you say we're bypassing
>>> NSDocument?
>>>
>>> Not necessarily NSDocument, but when you save, it posts a
>>> notification
>>> that calls finalizeChanges: on open editors, right? That does a
>>> brute
>>> force end editing, and the document is saved in spite of any
>>> alerts in
>>> the editor; I think we should fail to save. It seems preferable
>>> to do
>>> something conceptually like this in the document:
>>>
>>> - (BOOL)canSaveDocument{
>>> NSWindowController *wc;
>>> NSArray *editors = [self windowControllers];
>>> for(wc in editors) {
>>> if ([wc isBibEditor] && [wc didValidate] == NO)
>>> return NO;
>>> }
>>> return YES;
>>> }
>>>
>>> - (IBAction)saveDocument:(id)sender
>>> {
>>> if ([self canSaveDocument])
>>> [super saveDocument:sender];
>>> else NSBeep()
>>> }
>>>
>>> That would probably be better, if it could work (see below).
>>>
>>>
>>> where didValidate would simply check [[self window]
>>> makeFirstResponder:nil]. That should cause any formatters to fire
>>> and
>>> check their contents, with no forceEndEditing. Same thing in
>>> windowShouldClose; it should return NO if [[self window]
>>> makeFirstResponder:nil] fails, not if it has an attached sheet as a
>>> side effect of the finalize call.
>>>
>>> There's likely stuff I'm forgetting or just don't see, but it seems
>>> like that could simplify the validation code at least. I can't
>>> figure
>>> out editing; we have a mix of NSControl/NSText/NSFormatter delegates,
>>> and also the recordChangingField:toValue: and
>>> userChangedField:from:to: stuff...it's not clear which is used for
>>> what.
>>>
>>> --
>>> adam
>>>
>>> I also don't like all the different validations. Note that
>>> recordChangingField:... and userChangedField:... have nothing to do
>>> with validation, they are just wrappers around changing a value and
>>> whatever needs to be done (like autogeneration and scripthooks).
>>
>> Yeah, I guessed as much, but recordChangingField was only called from
>> on place, and other code was doing the setting separately. That was a
>> separate confusion that slipped in while I was typing that message and
>> reading the code :).
>>
>
>I just changed that, it's now called from some other places as well
>(drag/drop support). I think it used to be called also from the drag/
>drop support of the form, at least at some point.
>
>>> But I don't think we can put the validation in one place. Some
>>> validation happens only when the value is committed, as it cannot be
>>> handled by the formatter (e.g. the crossref chain problem). Although
>>> that could perhaps go into control:textShouldEndEditing:.
>>
>> That's a good point. I realized that eventually when trying to figure
>> out why the citekey was validated twice.
>>
>> I wonder if we need (all) of those formatter delegate methods?
>> There's some modal dialog hell going on there. The complex string
>> formatter can't enforce balanced braces, of course, so it can't do the
>> partialString validation. The cite key field can (and now does), so
>> maybe those alerts don't need to be shown?
>
>I'm not sure which alert you're alluding to here?
there's duplication now:
control:didFailToValidatePartialString:errorDescription: and
control:didFailToFormatString:errorDescription: may both be used. the citekey
field picks up all 3 of those, I think, which is confusing to read (partly due
to fragileCiteKeyCharacterSet check).
>
>> I recall thinking it was
>> best to show alerts at one point, but as a user I get annoyed at them.
>>
>
>I think that when we revert changes or prevent committing we need to
>show an alert.
>
>>> What about a window close when the app quits? That does not use
>>> windowShouldClose.
>>
>> Well, the document could refuse to allow application termination via
>> applicationShouldTerminate: if the normal validation path fails.
>>
>
>I'm not sure about the different notifications that go on and the
>order of them. Also note that when the app terminates windows are
>closed without going through notifications.
applicationShouldTerminate: is specifically for documents to refuse or delay
termination, so the document could make the validation checks or even call the
window close delegate method (NSApplicationTerminateReply).
>Also when the fields are changed they have to stop editing, otherwise
>the UI is in an inconsistent state wrt to the data.
You mean the typeInfoChange: notification? It's not going to be inconsistent
wrt the BibItem, because the BibItem doesn't change. It'll be out of sync with
the prefs, in that it won't be displaying some field the user just added, but
that sounds like an edge case. It requires you to have an invalid, uncommitted
edit, and make a change in the prefs. Closing the editor and reopening it
would take care of that. A more common case might be invalid, uncommitted edit
and changing the type popup; in that case, the popup change should be refused
until the problem is fixed.
-------------------------------------------------------------------------
SF.Net email is sponsored by:
Check out the new SourceForge.net Marketplace.
It's the best place to buy or sell services
for just about anything Open Source.
http://ad.doubleclick.net/clk;164216239;13503038;w?http://sf.net/marketplace
_______________________________________________
Bibdesk-develop mailing list
Bibdesk-develop@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bibdesk-develop
