[Pythonmac-SIG] AppleScript Guru Wanted

Vincent Marchetti vincem@en.com
Mon, 2 Oct 2000 21:43:38 -0400


Recently, Jack Jensen posed two problems with scripting Mac applications
through
OSA:

>Hi folks,
>I just ran into a problem with MacPython OSA support. Two problems,
>actually:
>1. The CodeWarrior suite declares both a property "project document"
>and a class "project document". As you wil understand this does not
>work well, as these both end up in the same namespace, and both with
>the same name "project_document". Is it legal OSA to have properties
>and classes with the same name? If it is: can anyone think of a
>workaround for MacPython?
>

I at first replied that I had problems with apps I had written, in which I
shared names between AppleEvent classes and properties. It appears that the
scripting interface to CodeWarrior has this sharing as Jack explains above.
I have since checked, and it appears that the interface to CodeWarrior
DOESN'T WORK!. That is, when I try in AppleScript (via the Script Debugger)
to try this script:

tell application "CodeWarrior IDE 4.0"
  get project document of target 1 of front document
end tell

No result is returned, no result and no error. However, when the property
"project document" is explicitly specified, as in:

tell application "CodeWarrior IDE 4.0"
  get =ABproperty PrjD=BB of target 1 of front document
end tell

the appropriate object reference is returned.

I think it's fair to say that such name sharing is not supported in
AppleScript, and it doesn't seem to make sense to jump hoops in a Python
scripting system to allow it.

I have also looked back at my own apps that tried to share names, and I saw
that I had to do some kludgy things in the Apple Event handling to decode
the events sent by AppleScript.



>2. Aepack does not handle passing classes as arguments. If anyone
>feels like fixing this: please be my guest. The symptom is that if you
>do "xxx.make(new=3Dclassname)" it should pass
>aetypes.Type(classname.wantd). Hmm, maybe if this is fixed the
>previous problem isn't a problem anymore.... Oh sigh, my brain always
>turns inside out when I try to reason about OSA:-(
>
>Any help is appreceated,


I at first replied that I just use
xxx.make(new =3D classname.want)
but I now realize that this assumes that the receiving application is
clever enough to convert the 4 character 'want' string to an Apple Event
type, and apps written using the Metrowerks PowerPlant framework are this
clever. However, a better solution is to add the following choice to the
long list of choices in the pack function from module aepack:

def pack(x, forcetype =3D None):
	...
	t =3D type(x)
	...
	# add this to correctly pack class specifications
	if t =3D=3D ClassType and issubclass(x, aetypes.ObjectSpecifier): #
issubclass Python builtin function
		return aetypes.Type(x.want).__aepack__()
	# end of class specification packing
	...

This change allows the syntax Jack suggests above.

Vince Marchetti