On Thursday, January 03, 2008, at 03:37PM, "Christiaan Hofman" <[EMAIL
PROTECTED]> wrote:
>
>On 4 Jan 2008, at 12:34 AM, Adam R. Maxwell wrote:
>
>>
>> On Thursday, January 03, 2008, at 02:17PM, "Christiaan Hofman"
>> <[EMAIL PROTECTED]> wrote:
>>>
>>> On 3 Jan 2008, at 10:57 PM, Adam R. Maxwell wrote:
>>>
>>>>
>>>> On Thursday, January 03, 2008, at 01:39PM, "Christiaan Hofman"
>>>> <[EMAIL PROTECTED]> wrote:
>>>>>
>>>>> On 3 Jan 2008, at 10:27 PM, Adam R. Maxwell wrote:
>>>>>
>>>>>>
>>>>>> On Thursday, January 03, 2008, at 12:25PM, "Christiaan Hofman"
>>>>>> <[EMAIL PROTECTED]> wrote:
>>>>>>>
>>>>>>> On 3 Jan 2008, at 8:55 PM, Adam R. Maxwell wrote:
>>>>>>>
>>>>>>>> Okay, that's right. There's still a retain cycle in the
>>>>>>>> migration
>>>>>>>> controller that should be unnecessary. When the document window
>>>>>>>> closes, it closes the migration window regardless of what it's
>>>>>>>> doing at the time.
>>>>>>>>
>>>>>>>
>>>>>>> Why is there a retain cycle? And shouldn't the migration be
>>>>>>> stopped
>>>>>>> when the document window closes?
>>>>>>
>>>>>> Yes, it should be stopped, but can the document window actually
>>>>>> close before this stops? I can't make it do that.
>>>>>>
>>>>>> If I brute-force a document close like this
>>>>>>
>>>>>> if (current > 200) {
>>>>>> [[self document] close];
>>>>>> NSLog(@"closed document %@", [self document]);
>>>>>> }
>>>>>>
>>>>>> in the loop, the document clears the window controller's
>>>>>> backreference. Since the enumerator retains the publications
>>>>>> array, it just exhausts the loop and then sends [nil
>>>>>> updatePreviews]. It's not a big deal, but it's nice to avoid
>>>>>> extra
>>>>>> bookkeeping if the kit already takes care of it.
>>>>>
>>>>> But if the migration window closes the document will also be
>>>>> cleared,
>>>>> but then it should still send updatePreviews when it finishes.
>>>>> That's
>>>>> why the document should be retained. So this is not a good example.
>>>>
>>>>>>>>>>> + // keep a reference to the document, because it may go
>>>>>>>>>>> away
>>>>>>>>>>> when the window closes while we're busy
>>>>
>>>> So the comment refers to closing the migration window? I'm not
>>>> able to close that before the loop finishes, either. If this were
>>>> possible, though, shouldn't it send -stop when the migration window
>>>> closes? This isn't working in a separate thread, so I don't see
>>>> why anything, let alone the document, needs to stop it.
>>>
>>> It may be hard, but as the main thread is run it's not impossible.
>>> I'm not sure if it should be stopped when the window closes, without
>>> any warning. Though I don't trust it when it would go on modifying
>>> the items after the document window closes.
>>
>> Hmm...I guess it partly depends on how sendEvent: and NSRunLoop
>> interact. If that's a concern let's just remove the NSRunLoop call
>> and replace it with [[self window] displayIfNeeded]. Then there
>> will certainly be no event processing until that method exits.
>
>But it has the disadvantage that you get the beach ball.
There's a progress bar so the user knows that something is happening. I think
the beachball is correct in this situation, actually; that bugged me about
running the runloop, since you can't actually do anything with the UI (click
buttons etc), but it looks as if you could.
-------------------------------------------------------------------------
This SF.net email is sponsored by: Microsoft
Defy all challenges. Microsoft(R) Visual Studio 2005.
http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/
_______________________________________________
Bibdesk-develop mailing list
Bibdesk-develop@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bibdesk-develop
