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. > > > 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. ------------------------------------------------------------------------- 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
