• Open Menu Close Menu
  • Apple
  • Shopping Bag
  • Apple
  • Mac
  • iPad
  • iPhone
  • Watch
  • TV
  • Music
  • Support
  • Search apple.com
  • Shopping Bag

Lists

Open Menu Close Menu
  • Terms and Conditions
  • Lists hosted on this site
  • Email the Postmaster
  • Tips for posting to public mailing lists
Re: filtering with master-detail and core data
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: filtering with master-detail and core data


  • Subject: Re: filtering with master-detail and core data
  • From: Matt Neuburg <email@hidden>
  • Date: Fri, 13 Jan 2006 10:06:11 -0800
  • Thread-topic: filtering with master-detail and core data

On Tue, 10 Jan 2006 11:30:19 -0800, Matt Neuburg <email@hidden> said:
>My Core Data app uses a basic master/detail interface. There is one
>NSArrayController bound to the managed object context and specifying the
>"Entry" entity, and to that there are bound two interface items:
>
>(1) The column of a one-column NSTableView. It shows the "date" property
>from every "Entry" (master), thru the arrangedObjects of the
>NSArrayController.
>
>(2) An NSTextView. It shows the "fact" property of the currently selected
>"Entry" (detail), thru the selection of the NSArrayController.
>
>So far, so simple. Now then. Under certain circumstances (e.g. the user does
>a search), I filter the NSArrayController, using setFilterPredicate. This
>works, but a Bad Thing happens: the master-detail becomes slooooow,
>especially if this is a regex search ("matches"). You click on a row of the
>NSTableView, and a long time later (five or ten seconds), the NSTextView
>changes to show the detail for that selection.
>
>I'm guessing that what's happening is that the NSArrayController is doing
>the search anew, every time the selection changes. That is not what I was
>expecting. I was expecting that the arrangedObjects would be changed to
>consist of just the results of the search; thus, selecting would be
>instantaneous because the search has already been performed. But that's not
>true, so obviously I've set this up wrong.
>
>My question is, how should I have set it up? I can think of three general
>approaches:
>
>* Front end. Instead of binding the NSArrayController to the Entry entity, I
>maintain the set of Entries in code and bind the NSArrayController to the
>maintained set.
>
>* Middle. Subclass the NSArrayController to behave the way I expect, rather
>like mmalc's FilteredArrayController.
>
>* Back end. Bind a second NSArrayController to the first. The first does the
>filtering and the second runs the master-detail interface.
>
>I tried the third approach and it didn't help. What should I in fact be
>doing? Thx - m.

And the answer is: (e), none of the above. The solution is to set the
NSArrayController's fetchPredicate instead of its filterPredicate. m.

--
matt neuburg, phd = email@hidden, <http://www.tidbits.com/matt/>
A fool + a tool + an autorelease pool = cool!
AppleScript: the Definitive Guide
<http://www.amazon.com/exec/obidos/ASIN/0596005571/somethingsbymatt>



 _______________________________________________
Do not post admin requests to the list. They will be ignored.
Cocoa-dev mailing list      (email@hidden)
Help/Unsubscribe/Update your Subscription:

This email sent to email@hidden

  • Prev by Date: Re: Cocoa Custom NSCell Binding Issue
  • Next by Date: confusing Protocol error <SOLVED>
  • Previous by thread: filtering with master-detail and core data
  • Next by thread: Sync Services: role of client type
  • Index(es):
    • Date
    • Thread