Re: Script commands and the application object
Re: Script commands and the application object
- Subject: Re: Script commands and the application object
- From: Greg Titus <email@hidden>
- Date: Wed, 20 Mar 2002 10:54:14 -0800
On Wednesday, March 20, 2002, at 01:40 AM, email@hidden wrote:
The only objection I have is that I'd like my app *delegate* to be
declaring this method, the same way I have it handling my key-value
coding using application:delegateHandlesKey:. But I can't find any way
to do this; it seems like my delegate has no way of getting in the loop
for script commands. I don't really like having this stuff in my
NSApplication subclass; it just has to talk to the delegate to get any
of its work done anyway.
Is there a mechanism I'm missing that allows me to do this? I've
been combing the doc for one, but it's not jumping out at me...
I haven't found any way to do this yet.
Oh, and by the way: my command has no arguments, but I can't get
Script Editor to stop displaying it as "timedCopyImage reference --
the object for the command". Invoking it simply as "tell application
'Constrictor' timedCopyImage end tell" works fine, it really has no
argument. Why is Script Editor doing this? Is this a bug, or a
subtlety of AS I'm ignorant of?
There is a way to specify that there is no direct object in an AETE
resource (which is what AppleScript generates the dictionary from), but
there is currently no way to specify this in
.scriptSuite/.scriptTerminology files (which is what Cocoa generates the
AETE resource from).
tell application "Constrictor"
set frame to {100, 100, 128, 128}
end tell
fails in all cases.
replaceValueAtIndex:inPropertyWithKey:withValue: gets the value of
the key again, presumably to have something to stuff into; but this
ultimately fails, for reasons that are not clear to me. (All
ScriptEditor gives me is an NSInternalScriptError, and
handleTakeValue:forUnboundKey: is never called). It's unclear why
NSSetCommand got the key's value before calling
replaceValueAtIndex:inPropertyWithKey:withValue:, given that it doesn't
seem to have any use for it -- perhaps it was checking that an element
at index 0 existed before trying to set it?
Okay, here's my guess:
I bet that the initial -valueForKey: call is being made on 'frameRect'
simply to check whether the result is a single object or an array. Since
you are returning an array, -makeReceiver:takeValue: decides to use the
array method -replaceValueAtIndex:inPropertyWithKey:withValue: instead
of the single-object -takeValue:forKey:.
A small piece of evidence that the scripting key-value coding is built
with mixed single/multiple value support is in this comment in
NSScriptKeyValueCoding.h:
- (id)valueAtIndex:(unsigned)index inPropertyWithKey:(NSString *)key;
// Retrieve a single value from a multi-value key. This actually
works with a single-value key as well if the index is 0.
// The method valueIn<Key>AtIndex: will be used if it exists
So then the implementation of
-replaceValueAtIndex:inPropertyWithKey:withValue: tries to see if you've
implemented -replaceInFrame:atIndex: (see comments in that header
again), sees that you haven't implemented it, and falls back on
its default strategy. It grabs the current array again with
-valueForKey:, in order to stuff the new value into index 0. (As you
suspected.)
The NSInternalScriptError means that during the processing something
raised an NSException. Add a breakpoint to -[NSException raise] to find
out where that is happening. (My guess is somewhere it is attempting to
-insertObject:atIndex: on a non-mutable array, but that's just a guess.)
Hope this helps,
--Greg
_______________________________________________
cocoa-dev mailing list | email@hidden
Help/Unsubscribe/Archives:
http://www.lists.apple.com/mailman/listinfo/cocoa-dev
Do not post admin requests to the list. They will be ignored.