Apple, the Apple logo, and Macintosh are registered trademarks of Apple Computer, Inc.
Mac and OpenDoc are trademarks of Apple Computer, Inc.
Disposing tokens (Not a problem, but a caveat.)
The “user” token obtained from ODNameResolver::GetUserToken should never be disposed by your part editor. OpenDoc will dispose this for you. If you implement as dispose token proc, however, that proc can and should dispose of the ODOSLToken passed in as well as any other auxiliary storage associated with this token.
Creating copies of Apple events with ODDescTOAEDesc
If you send a Semantic Event to yourself and, in your handler, you make a copy of the event with ODDescToAEDesc, you will not be able to dispose the copy. AEDisposeDesc will refuse to dispose it. This problem will be addressed in future releases of OpenDoc.
Reentrancy of ODNameResolver::Resolve
This method is supposed to be reentrant, but a problem identified at the last minute prevented it. It will be fully reentrant in the next release.
Documents created from stationery (mismatched Finder and Process Manager names)
When a document is created from stationery, the stationery is launched by the process manager, but the newly created document is then attached to the existing process by OpenDoc. The name of the document in the application menu is the name of the stationery document, but OpenDoc thinks the name is the new document name. When AppleScript searches by name for an application to target, it first checks the application menu, and it will match against the stationery file name. Subsequent launches of the document won’t have this problem. The first time the document is launched, you will need a tell statement like this (typically):
tell application "TextEditor 1.0"
The next time(s) you will have to change it to something like this:
tell application "TextEditor 1.0 5/7/95"
Some scripts that fail
There seem to be some problems with lists and whose clauses. We have just reproduced the Quality Engineer’s bug report here as the problem is not easy to state in a few sentences.
“NOTE: this is a long bug description. But the problem is easy to demonstrate. 'part 1 of every part' works. 'part 1 of every part whose <some condition>' doesn't work. Even when the two "every's" refer to exactly the same list of parts.
Open a ContainerDoc root, embed two ContainerParts in it, and embedd two ContainerParts in each of the embedded parts. So you have two levels of embedding.
If you say 'every part', you get a list of the two 1st-level embedded parts. Fine.
If you say 'every part whose name = "Page Layout"', you get exactly the same list. Also fine. (Every embedded ContainerPart starts out with the name "Page Layout".)
However, these two phrases don't act the same if you try to access elements from them. If you say 'part 1 of every part', you get what you should: a 2-element list consisting of the first part of part 1 and the first part of part 2 (that is, two of the four doubly-embedded parts). But if you say 'part 1 of every part whose name = "Page Layout"', which ought to be the same, you get . . . something different.
(What you get depends on how you parenthesize. A simple 'part 1 of every part whose name = "Page Layout"' gets a Script Editor "Can't get . . ." error. If you try 'part 1 of (every part whose name = "Page Layout")' instead, you get the descriptor for the first embedded part - 'part id 65638 of application "my doc"' - which is way wrong. Parentheses don't seem to matter for the simpler 'part 1 of (every part)'.)
This seems to only be a problem with element acessors ('part 1 of') and not property accessors. 'id of every part' and 'id of every part whose name = "Page Layout"' both give you just what they ought to (in both cases the same thing).”
Memory Leaks
We inadvertantly introduced a large number of memory leaks into the Semantic Events subsystem at one point. We have tried to cap these leaks, but, since it was at the last minute, but we’re afraid that we did not get all of them. Certain scripts will cause more memory leaks than others. If you are developing a script, you may have to relaunch your document from time to time in order to free up memory.
Apple, the Apple logo, and Macintosh are registered trademarks of Apple Computer, Inc.
Mac and OpenDoc are trademarks of Apple Computer, Inc. (Palatino/10/Plain)
Heading1 (Helvetica/12/Bold/Underline)
OpenDoc provides the user the ability to do AbstractAction. (Palatino/10/Plain)
Heading2 (Helvetica/10/Bold)
OpenDoc provides the user the ability to do AbstractAction. A part editor needs to help implement this piece of functionality. This document contains the list of part editor responsibilities, and sample code which would allow a part editor to fullfil these responsibilities. (Palatino/10/Plain)
Caveats (Helvetica/10/Bold)
• This code does not contain proper error checking
• It does not account for the case where a part may want to do AbstractTertiaryCase.
• It uses the PlatformFile class which is an unsupported private utility class of OpenDoc (Palatino/10/Plain)
