Re: Scripting Bridge && filteredArrayUsingPredicate
Re: Scripting Bridge && filteredArrayUsingPredicate
- Subject: Re: Scripting Bridge && filteredArrayUsingPredicate
- From: has <email@hidden>
- Date: Wed, 2 Jan 2008 13:40:38 +0000
On 29 Dec 2007, at 16:28, email@hidden wrote:
On a similar note, I recently stumbled upon what appears to be another
major flaw in filteredArrayUsingPredicate:. If the predicate is set to
match an empty string "" (a common enough operation when dealing with
meta tags, for example in iTunes), filteredArrayUsingPredicate: always
returns an empty array, regardless if the objects in the unfiltered
array matches the predicate or not.
Seems to work here. One reason you might not get matches is if you're
using an empty string where some other value is expected (integer,
'missing value' constant, etc).
(as you
cannot remove an object from an SBElementArray, although it is
declared as a subclass of NSMutableArray)
Deleting elements should be done via the application's 'delete'
command. For whatever reasons, the familiar -[NSMutableArray
removeObject...] methods aren't mapped to Apple events.
This leads me to another question: how do I create a new
SBElementArray?
You don't. They're returned by SB when it needs to represent one-to-
many relationships.
The thing to realise about Scripting Bridge is that it bears precious
little resemblance to the way that Apple event IPC actually works. SB
goes to considerable lengths to pretend that it's a typical object-
oriented mechanism a-la COM or DO. But it's not: it's RPC plus simple
relational queries, and you don't have to scratch too deep before the
faux-object-oriented facade starts to come apart. Google around if you
want to read some of my other rants on the subject.
Anyway, my advice FWIW would be: 1. learn how Apple event IPC really
works, and 2. use appscript to do it. Yes, there's a bit more of a
learning curve with this approach, since appscript approaches Apple
event IPC on its own terms and doesn't try to sweep its complexities
and warts under the rug and pretend they don't exist. But that's the
nature of the AppleScript beast, and if you want to work with it
effectively then it's something you just gotta deal with.
HTH
has
--
http://appscript.sourceforge.net
http://rb-appscript.rubyforge.org
_______________________________________________
Cocoa-dev mailing list (email@hidden)
Please do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins(at)lists.apple.com
Help/Unsubscribe/Update your Subscription:
This email sent to email@hidden