Peter N Lewis wrote:
I'm no Cocoa expert, but I think you're wrong on this, you've missed
out a crucial line:
At 3:12 PM -0400 11/8/08, Sean DeNigris wrote:
// Get uid to return
NSString* todoUid = [newTodo uid];
// Clean up
[newTodo release];
newTodo = nil;
return todoUid;
[newTodo release] is not [newTodo autorelease]. So it may
immediately call dealloc and dealloc the uid returned by by [newTodo
uid].
I don't think so.
The problem here is that you're thinking about Scripting Bridge in
conventional Cocoa/proxy object terms. This is understandable given
that this is the illusion that the SB API is intended to create.
*However*, the thing to realise about Apple event IPC is that it's
*RPC plus queries* (a very un-Cocoa-like beast), and what SB does is
plaster over this mechanism with a load of obfuscations in a well-
meaning (but misguided) attempt to make it look and feel like regular
Cocoa (which it isn't, and never will be).
For example, the whole:
iCalTodo* newTodo = [[[iCal classForScriptingClass:@"todo"]
alloc] init];
[[myCalendar todos] addObject:newTodo];
[newTodo release];
rigmarole is just a bunch of pseudo Cocoa-isms on top of a standard
'make' Apple event, which in AppleScript would appear as:
tell application "iCal" to make new todo at end of todos
and in objc-appscript - which, unlike SB, is bluntly honest about
what's going on beneath - as:
ICCommand *cmd = [[[iCal make]
new: [ICConstant todo]];
at: [[ICApp todos] end]];
id result = [cmd send];
(I'll spare you the equivalent C though as we'd be here all day.)
Basically, all that SB is doing in that first line is creating a
temporary SB object representing an application object that doesn't
actually exist yet. This SB object contains one or more values that
will be used as parameters to a 'make' event that will be sent later.
(The one parameter that's always required is 'new'; others may be
optional or required depending on the application implementation, type
of object being created, etc.)
As soon as you pass this object to -addObject:, a 'make' event
containing those parameters is sent off to the target application to
handle. Once that's done, your original temporary object no longer has
any real part to play; unlike Distributed Objects, there is no
permanent two-way connection where a local object acts as the official
proxy for a remote object as long as both objects remain live.
The fact that you can subsequently refer to this temporary object to
set and get properties belonging to iCal's newly created todo object
is kinda incidental. All that's happening here is that SB is stuffing
the object specifier (i.e. query) returned by the 'make' command into
your SB object, and subsequently accessing that object's properties is
sending fresh 'get'/'set' events to the application with that object
specifier as their direct parameter.
However, even this aspect of SB's behaviour is misleading; for
example, some applications may not return a result for the 'make'
event (in which case you'll be talking to air), and many that do will
return a by-index or by-name reference that is not guaranteed to
identify the same application object the next time you want to talk to
it. Also bear in mind that setting properties after -addObject: is
called is not the same as setting them as part of the 'make' event;
for example, read-only properties can often have values assigned at
the time the object is created, but can't be set afterwards.
As for memory management of the NSString returned by [newTodo uid],
remember that it's the product of a 'get' event sent to the target
application, and not something that belongs to or held in an ivar of
the SB object that returned it. All SB does is add the NSString to the
current autorelease pool before returning it, so once that pool is
dealloced the NSString will be disposed of as well unless you -retain
it beforehand.
Anyway, hope that's of some use, though personally if I were the OP
I'd see about using Leopard's new Calendar Store framework instead,
thereby avoiding the need to muck about with Apple event IPC at all.
Users will also appreciate it, since it means that other applications
won't be magically launching while they're running yours.
HTH
has
--
Control AppleScriptable applications from Python, Ruby and ObjC:
http://appscript.sourceforge.net
_______________________________________________
Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)
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:
http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com
This email sent to [EMAIL PROTECTED]
