On Jan 20, 2008, at 5:45 PM, Christiaan Hofman wrote: > > > On Jan 21, 2008 2:37 AM, Adam R. Maxwell <[EMAIL PROTECTED]> wrote: > > On Jan 20, 2008, at 5:27 PM, Christiaan Hofman wrote: > > > > > > > On Jan 21, 2008 2:17 AM, Christiaan Hofman <[EMAIL PROTECTED] > > wrote: > > > > On 21 Jan 2008, at 1:28 AM, Adam R. Maxwell wrote: > > > > > > > > On Jan 20, 2008, at 4:14 PM, Christiaan Hofman wrote: > > > > > >> > > >> On 21 Jan 2008, at 1:12 AM, Adam R. Maxwell wrote: > > >> > > >>> > > >>> On Jan 20, 2008, at 4:00 PM, Christiaan Hofman wrote: > > >>> > > >>>> > > >>>> On 21 Jan 2008, at 12:53 AM, Adam R. Maxwell wrote: > > >>>> > > >>>>> > > >>>>> On Jan 20, 2008, at 3:46 PM, Christiaan Hofman wrote: > > >>>>> > > >>>>>>>>> True; the unarchiving can be done on the thread, though, > > >>>>>>>>> after - > > >>>>>>>>> init > > >>>>>>>>> has returned. It would just cut down on overhead in > case of > > >>>>>>>>> multiple > > >>>>>>>>> huge indexes stored on disk, so you wouldn't have to read > > all > > >>>>>>>>> of > > >>>>>>>>> them > > >>>>>>>>> fully in order to find the right one. > > >>>>>>>> > > >>>>>>>> Of course unarchiving on the thread would mean creating the > > >>>>>>>> index on > > >>>>>>>> the thread. And then we need safeguards in -index. (in the > > >>>>>>>> cancel > > >>>>>>>> method the lock is probably sufficient). > > >>>>>>> > > >>>>>>> I'd say just creating it as a local variable and then > > assigning > > >>>>>>> to > > >>>>>>> the > > >>>>>>> ivar when it's done is sufficient. The BDSKSearch now > > ignores a > > >>>>>>> NULL > > >>>>>>> index (but it won't get any delegate messages until the > > index is > > >>>>>>> fully > > >>>>>>> created anyway), so -index should be fine as-is. > > >>>>>> > > >>>>>> No that does not work. Apart from a failing OBPOSTCONDITION > > and a > > >>>>>> log, sometimes it does nothing. > > >>>>> > > >>>>> What does not work? And what sometimes does nothing? > > >>>> > > >>>> > > >>>> Creating the index in buildIndex... does not work. Sometimes > > there > > >>>> just happens nothing: no indexing, at least the UI does not > show > > >>>> the > > >>>> progress bar and nothing appears in the table. Also if I remove > > the > > >>>> OBPOSTCONDITION. > > >>> > > >>> I don't understand that. Is it raising an exception somewhere? > > The > > >>> OBPOSTCONDITION is just a harmless log message. > > >>> > > >>> If I move all the index creation stuff from -init to > > >>> buildIndexForItems: and make the document an ivar to get its URL > > >>> (not > > >>> safe, I know), it works fine. No postcondition log, progress > bar > > >>> works, and results show up in the table. > > >> > > >> For me sometimes it does, and sometimes it doesn't. > > > > > > That sounds most peculiar; I've tried several times here and it > > > works. Have you verified that your indexData and index ivars are > > non- > > > NULL before if ([signatures count])? And that buildIndexForItems: > > > gets called every time? > > > > The problem is in BDSKFileSearch. When the index is NULL *which can > > happen when it is created in the thread) the SKSearch is not > created, > > and the delegate method does nothing. > > > > so if the search is NULL then it should be created in the delegate > method. > > Yes, so it should not check for search != NULL.
right, it only checks for that to avoid a useless -cancel > > Moreover [searchIndex isIndexing] returns NO in that case, and the > > search will send a didFinishWithResults: delegate method, which > > hides the progress bar. So the whole logic of the delegate methods > > in BDSKFileSearch is wrong when the index can be NULL. > > The isIndexing method should never return NO during > buildIndexForItems:, though; why is it set to 0 there before calling > indexFilesForItems:..? I changed that a couple days ago to avoid that > race with the progress bar. > > It returns NO when the index has not been created yet. And > searchForString:withOptions: can be called before the index is > created, as it is called on the main thread and the index (in this > case) is created on the worker thread.There are other places where > isIndexing is set to 0 for a short while. The main thread could come > in there and catch that. It should not check for isIndexing, it > should check whether the index has finished. Perhaps by checking the > progressValue. That's the only thing isIndexing was intended for, though: to let the delegate know that not all results are available yet, so don't call didFinish: and stop the progress bar. I broke that somewhere along the line. It's really not supposed to be set to zero until all the initial stuff is done, and is ignored thereafter since the progress bar is only shown for the initial indexing (and in that light, it should be set to 1 at -init time). ------------------------------------------------------------------------- This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2008. 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
