crystal report export to pdf without viewer c# : Extract pages from pdf SDK software service wpf winforms web page dnn Applescript0-part486

AppleScript
WilliamR.Cook
UniversityofTexasatAustin
wcook@cs.utexas.edu
With contributions from Warren Harris, Kurt Piersol, Dave Curbow, Donn Denman,
Edmund Lai,Ron Lichty,Larry Tesler, Donald Olson,Mitchell Gass and Eric House
Abstract
AppleScript is a scripting language and environment for the
Mac OS. Originally conceived in 1989, AppleScript allows
end users to automate complex tasks andcustomize Mac
OS applications. To automate tasks, AppleScript provides
standard programming language features (control flow, vari-
ables, data structures) and sends Apple Events to invoke ap-
plication behavior. Apple Events are a variation on standard
remote procedure calls in which messages can identify their
arguments by queries that are interpreted by the remote ap-
plication. This approach avoids the need for remote object
pointers or proxies, and reduces the number of communi-
cation round trips, which are expensive in high latency en-
vironments like the early Macintosh OS. To customize an
application thatuses AppleScript’s OpenScripting Architec-
ture, users attach scripts to application objects; these scripts
can then intercept and modify application behavior.
AppleScript was designed for casual users: AppleScript
syntax resembles natural language, and scripts can be cre-
ated easily by recording manual operations on a graphical
interface. AppleScript also supported internationalization in
allowingscripttobe presentedinmultipledialects,including
English,Japanese, or French. Although the naturalistic syn-
tax is easy to read, it can make scripts much more difficult
to write.
Early adoption was hindered by the difficulty of mod-
ifying applications to support Apple Events and the Open
Scripting Architecture. Yet AppleScript is now widely used
and is an essential differentiator of the Mac OS. Apple-
Script’s communication model is a precursor to web ser-
vices, and the idea of embedded scripting has been widely
adopted.
Permissionto make digital or hard copies of all or partof thiswork for personal or
classroomuseisgrantedwithoutfeeprovidedthatcopiesare notmade or distributed
forprofitorcommercialadvantage andthatcopiesbearthisnotice andthe fullcitation
onthe first page.Tocopy otherwise,torepublish,toposton serversor toredistribute
tolists,requiresprior specificpermissionand/or afee.
Copyright
c
°
ACM[tobesupplied]...$5.00
Categories and Subject Descriptors D.3 [Programming
Languages]
General Terms Languages,Design,HumanFactors
Keywords AppleScript,Scripting,History
1. Introduction
The development of AppleScript was a long and complex
process that spanned multiple teams, experienced several
false starts and changes of plan, and required coordination
between different projects and companies. It is difficult for
any one person, or evena small group ofpeople,topresent a
comprehensive history of such a project, especially without
official support from the company for which the work was
done. The email record of the team’s communications have
been lost, and the author no longer has access to internal
specifications and product plans.
Nevertheless, I believe that the development of Apple-
Scriptis a story worth telling, and Ihave been encouragedto
attempt it despite the inherentdifficulty of the task.I can of-
feronly my ownsubjectiveviews onthe project,as someone
who was intimately involved with all its aspects.I apologize
in advance for errors and distortions that I will inevitably
introduce into the story, in spite of my best efforts to be ac-
curate.
Ifirst heard the idea of AppleScript over lunch with Kurt
Piersol in February of 1991. The meeting was arranged by
ourmutual friendJames Redfern.IknewJames fromBrown,
where he was finishing his undergraduate degree after some
time off, and I was working on my PhD. James and I both
moved to California at about the same time, in 1988. We
spenta lot oftime togetherand Ihad heardalittleabout what
he was up to, but he claimed it was secret. James arranged
the meeting because Kurt was looking for someone to lead
the AppleScripteffort,andI was looking forsomething new
to do.
For the previous two and a half years I had been work-
ing at HP Labs. I was a member of the Abel group, which
included Walt Hill, Warren Harris,Peter Canning, and Wal-
ter Olthoff. John Mitchell consulted with us from Stanford.
The group was managed by Alan Snyder, whose formaliza-
Permission  to  make  digital/hard  copy  of part  of  this  work  for  personal  or 
classroom use is granted without fee provided that the copies are not made or 
distributed for profit or commercial advantage, the copyright notice, the title of 
the publication, and its date of appear, and notice is given that copying is by 
permission of the ACM, Inc. To copy otherwise, to republish, to post on servers, 
or  to  redistribute  to  lists,  requires  prior  specific  permission  and/or  a  fee. 
Permission may be requested from the Publications Dept., ACM, Inc., 2 Penn 
Plaza,  New  York,  NY  11201-0701,  USA,  fax:+1(212)  869-0481, 
©2007 ACM 978-1-59593-766-7/2007/06-ART1 $5.00 
DOI 10.145/1238844.1238845 
http://doi.acm.org/10.1145/1238844.1238845
Permission to make digital/hard copy of part of this work for personal or 
classroom use is granted without fee provided that the copies are not 
made or distributed for profit or commercial advantage, the copyright 
notice, the title of the publication, and its date of appear, and notice is 
given  that  copying  is  by  permission  of  the  ACM,  Inc.  To  copy 
otherwise, to republish, to post on servers, or to redistribute to lists, 
requires  prior  specific  permission  and/or  a  fee.  Permission  may  be 
requested from the Publications Dept., ACM, Inc., 2 Penn Plaza, New 
York, 
NY 
11201-0701, 
USA, 
fax:+1(212) 
869-0481, 
permissions@acm.org
©2007 ACM 978-1-59593-766-7/2007/06-ART1 $5.00 
DOI 10.1145/1238844.1238845 
http://doi.acm.org/10.1145/1238844.1238845
1-1
Extract pages from pdf - application Library tool:C# PDF Page Extract Library: copy, paste, cut PDF pages in C#.net, ASP.NET, MVC, Ajax, WinForms, WPF
Easy to Use C# Code to Extract PDF Pages, Copy Pages from One PDF File and Paste into Others
www.rasteredge.com
Extract pages from pdf - application Library tool:VB.NET PDF Page Extract Library: copy, paste, cut PDF pages in vb.net, ASP.NET, MVC, Ajax, WinForms, WPF
Detailed VB.NET Guide for Extracting Pages from Microsoft PDF Doc
www.rasteredge.com
tion of object concepts [35] was one basis for the develop-
mentofCORBA. At HPLabs Ifinished writing myPhD the-
sis,A DenotationalSemantics of Inheritance[14,19],which
the Abel group used as the foundation for a number of pa-
pers.We publishedpapersoninheritance andsubtyping[18],
object-oriented abstraction [7, 16], mixins [5], F-Bounded
polymorphism [6], and a fundamental flawin the Eiffel type
system [15]. I continued some of the work, analyzing the
Smalltalk collection hierarchy [17], after I left HP.
Neartheendof1990HPLabs was undergoingareorgani-
zationand Iwas notsure Iwould fit intothenewplan.Inad-
dition, Iwas interested in making a change.I had developed
several fairly large systems as an undergraduate,including a
text editorand a graphical software design tool [39, 20] that
were used by hundreds of other students for many years. As
agraduate student I had focused on theory, but I wanted to
learn the process of commercial software development. Ap-
ple seemed like a reasonable place to try, so I agreed to talk
with Kurt.
1.1 AppleScript Vision—Over Lunch
Kurt and I hit it off immediately at lunch. Kurt Piersol is a
large, friendly, eloquent man who was looking for people to
workon the AppleScript project.Kurtgraduated with a B.S.
from the University of Louisville’s Speed Scientific School.
He then worked at Xerox, building systems in Smalltalk-
80 and productizing research systems from Xerox PARC.
Kurt was hired to work on AppleScript in 1989. He was
originally asked to work on a development environment for
the newlanguage, buteventuallytook onthe role of steering
the project.
Kurt and I discussed the advantages or disadvantages
of command-line versus graphical user interfaces. With
command-line interfaces, commonly used on Unix, users
frequently write scripts that automate repeated sequences of
program executions. The ability to pipe the output of one
programinto another program is a simple but powerful form
of inter-application communication that allows small pro-
grams to be integrated to perform larger tasks. For example,
one can write a script that sends a customized version of
atext file to a list of users. The
sed
stream editor can cre-
ate the customized text file, which is then piped into the
mail
command for delivery. This new script can be saved
as a mail-merge command, so that it is available for manual
execution or invocation from other scripts. One appealing
aspect of this model is its compositionality: users can create
new commands that are invoked in the same way as built-in
commands. This approach works well when atomic com-
mands all operate on a common data structure, in this case
text streams.It was not obvious that it would work for more
complex structured data, like images, databases, or office
documents, or for long-running programs that interact with
users.
With a graphical user interface (GUI) important func-
tions, including the mail-merge command described above,
are usually built into a larger product, e.g.a word processor.
AGUI application offers pre-packaged integrated function-
ality, so users neednotcombine basic commands to perform
common tasks. Although careful design of graphical inter-
faces eliminates the need for automation for basic use, there
are still many tasks that users perform repeatedly within a
graphical interface. The designers of the graphical interface
cannot include commands to cover all these situations —
if they did, then some users would execute these new com-
mands repeatedly.Nofinite setofcommands caneversatisfy
all situations.
Most users are happy with GUI applications and do not
need a command-line interface or a scripting language. But
there are clearly some limitations to the GUI approach on
which Macintosh OS was based. Power users and system
integrators were frustrated by the inability to build custom
solutions by assembling multiple applications and special-
izing them to particular tasks. Allowing users to automate
the tasks that are relevant to them relieves pressure on the
graphical user interface to include more and more special-
ized features.
The vision for AppleScript was to provide a kind of
command-line interface to augment the power of GUI ap-
plications and to bring this power to casual users.
1.2 Automation and Customization
Kurt and I talked about two ways in which scripts and
GUI applications could interact:forautomation and forcus-
tomization.Automation means that a script directs an ap-
plication to perform a sequence of actions—the actions are
performed “automatically” ” rather than manually. With au-
tomation, the script is in control and one or more applica-
tions respond to script requests.Customizationoccurs when
ascript is invoked from within an application—the script
can perform “custom”actions that replace or augment the
normal application behavior. With customization, the appli-
cation manages and invokes scripts that users have attached
to application objects. Automation is useful even without
customization, but customization requires automation to be
useful.
We discussed whether there was sufficient benefit in pro-
viding a standard platform for scripting, when custom so-
lutions for each application might be better. Some applica-
tions alreadyhad their ownmacrocapability or aproprietary
scriptinglanguage. However, this approach requires users to
learn a different scripting language to automate each appli-
cation. These languages typically include some variation on
the basic elements of any programming language,including
variables, loops, conditionals, data types, procedures, and
exceptions. In addition, they may include special forms or
constructs specific to the application in question. For exam-
ple, a spreadsheet language can refer to cells, sheets, equa-
tions and evaluation.
One benefit of a standard scripting platform is that appli-
cations can then beintegrated with each other. This capa-
1-2
application Library tool:C# PDF Text Extract Library: extract text content from PDF file in
inputFilePath); PDFTextMgr textMgr = PDFTextHandler.ExportPDFTextManager(doc); // Extract text content C# example code for text extraction from all PDF pages.
www.rasteredge.com
application Library tool:C# PDF Image Extract Library: Select, copy, paste PDF images in C#
Image: Extract Image from PDF. |. Home ›› XDoc.PDF ›› C# PDF: Extract PDF Image. How to C#: Extract Image from PDF Document.
www.rasteredge.com
bility is important because users typically work with mul-
tiple applications at the same time. In 1990, the user’s op-
tions for integrating applications on the Macintosh OS were
limited to shared files or copy/paste with the clipboard. If
arepeated task involves multiple applications, there is lit-
tle hope that one application will implement a single com-
mand to perform the action. Integrating graphical applica-
tions canbe done atseverallevels: visualintegration,behav-
ioral integration, or data integration.Visualintegration in-
volves embedding one graphical component inside another;
examples include arunningJavaappletinside a web page,or
aspecializedorganization chart component displayed inside
aword-processing document.Behavioralintegrationoccurs
when two components communicate with each other; exam-
ples include workflow or invocation of a spell-check com-
ponent from within a word processor.Dataintegrationoc-
curs wheneveroneapplicationreads a file (orclipboarddata)
written by another application. A given system can include
aspects of all three forms of integration.
Iagreed with Kurt that the most important need at that
timewas forbehavioralintegration.Tocompete withcustom
application-specific scripting languages,AppleScript would
have to allow application-specific behaviors to be incorpo-
rated intothe language in as natural a wayas possible,while
preserving the benefits of a common underlying language.
The core of the language should support the standard fea-
tures of a programming language, including variables, pro-
cedures,and basic data types.Anapplication then provides a
vocabulary of specific terminology that applyto the domain:
a photo-processing application would manipulate images,
pixels andcolors,while a spreadsheetapplicationwouldma-
nipulate cells, sheets, and graphs. The idea of AppleScript
was to implement the “computer science boilerplate”once,
while seamlessly integrating the vocabulary of the applica-
tion domain so that users of the language can manipulate
domain objects naturally.We discussed the vision of Apple-
Script as a pervasive architecture for inter-application com-
munication, so that it is easy to integrate multiple applica-
tions with a script, or invoke the functionality of one appli-
cation from a script in another application. We hoped that
scripting would create a “network effect”, by which each
new scriptable application improves the value of scripting
for all other applications.
1.3 AppleScript Begins
Soon after, Kurt offered me a job and I accepted quickly.
This event illustrates one of the recurring characteristics of
AppleScript:thebasicidea isso compellingthat it is enthusi-
astically embraced by almost every software developer who
is exposed toit.
What was not immediately obvious was how difficult the
vision was to achieve—not forstrictlytechnical reasons, but
because AppleScript required a fundamental refactoring, or
at least augmentation, of almost the entire Macintosh code
base.The demonstrable benefits of AppleScript’s vision has
led developers to persevere in this massive task for the last
twentyyears; yettheworkistrulySisyphean,inthatthe slow
incremental progress has been interrupted by major steps
backward, first when the hardware was changed from the
Motorola 68000 chip to the IBM PowerPC, and again when
the operating system was reimplemented for Mac OS X.
At this point it is impossible to identify one individual
as the originator of the AppleScript vision. The basic idea
is simple and has probably been independently discovered
many times. The AppleScript team was successful in elab-
orating the original vision into a practical system used by
millions of people around the world.
2. Background
When I started working at Apple in April 1991 I had never
used a Macintosh computer. My first task was to understand
the background and context in which AppleScript had to be
built.
The main influences I studied were the Macintosh op-
erating system, HyperCard, and Apple Events. HyperCard
was a good source of inspiration because it was a flexible
application development environment with a scripting lan-
guage embedded within it. A previous team had designed
and implemented Apple Events to serve as the underlying
mechanismfor inter-application communication.The Apple
Events Manager had to be shipped early so that it could be
includedin the MacintoshSystem7 OSplanned for summer
1991. When I started at Apple, the Apple Event Manager
was infinalbeta testing.The factthat AppleScript and Apple
Events werenotdesigned togetherproved tobe a continuing
source of difficulties.
Macintosh systems at that time had 4 to 8 megabytes of
random-access memory (RAM) and a 40- to 60-megabyte
hard drive. They had 25-50 MHz Motorola 68000 series
processors. The entire company was internally testing Sys-
tem 7.0,a major revisionof the Macintosh OS.
Applications on the Macintosh OSwere designed around
amain event processing loop, which handled lower-level
keyboard and mouse events from the operating system [12].
The OS allowed an application to post a low-level event
to another application, providing a simple form of inter-
application communication. In this way one application
coulddrive another application,by sending synthetic mouse
and keyboard events that select menus or data and enter text
into an application. This technique was used in two utility
applications, MacroMaker and QuicKeys, which recorded
and played back low-level user interface events. It was also
used in the Macintosh help system, which could post low-
level events to show the user how to use the system. Scripts
that send low-level events are fragile, because they can fail
if the position or size of user interface elements changes
between the time the script is recorded and when it is run.
They are also limited in the actions they can perform; low-
1-3
application Library tool:VB.NET PDF Text Extract Library: extract text content from PDF
PDF ›› VB.NET PDF: Extract PDF Text. VB.NET PDF - Extract Text from PDF Using VB. How to Extract Text from PDF with VB.NET Sample Codes in .NET Application.
www.rasteredge.com
application Library tool:C# PDF Page Insert Library: insert pages into PDF file in C#.net
doc2.Save(outPutFilePath); Add and Insert Multiple PDF Pages to PDF Document Using C#. Add and Insert Blank Pages to PDF File in C#.NET.
www.rasteredge.com
level events can be used to change the format of the current
cell in a spreadsheet, but cannot read the contents ofa cell.
In the following section I describe these systems as they
were described to me at the start of the AppleScript project,
in April 1991.
2.1 HyperCard
HyperCard [27, 30], originally released in 1987, was the
most direct influence on AppleScript. HyperCard is a com-
bination of a simple database, a collection of user interface
widgets, and an English-like scripting language. These el-
ements are organized around the metaphor of information
on a collection of index cards. A collection of such cards
is called astack. A card could contain text, pictures, but-
tons, and other graphical objects. Each object has many
properties,includinglocationonthecard,size,font,style,
etc. Cards with similar structure could use a commonback-
ground;abackgrounddefinesthestructure,butnotthecon-
tent, of multiple cards. For example, a stack for household
information might contain recipe cards and contact cards.
The recipe cards use a recipe background that includes text
fields for the recipe title, ingredients, and steps. The contact
cards use a contact background with appropriate fields, in-
cluding a photo.
HyperCard scripts are written in HyperTalk, an English-
like scripting language [28]. The language is for the most
part a standard structured, imperative programming lan-
guage. However, it introduced a unique approach to data
structures: the stack, cards, objects and properties are used
to store data. These structures are organized in a contain-
ment hierarchy: stacks contain cards, cards contain objects,
and properties exist on stacks, cards, and objects. This pre-
defined structure makes it easy to build simple stacks, but
more difficult to create custom data structures.
Scripts in a stack can refer to the objects, collections of
objects, and their properties by usingchunkexpressions. A
chunk expression is best understood as a kind of query. For
example, the following chunk expression refers to the text
style property of a word element in a field of the current
card:
the textStyle of word 2
of card fleld "Description"
Achunk expression can refer to properties and elements of
objects. A property is a single-valued attribute, for example
textStyle
.Elements arecollections ofobjectsidentified by a
type,forexample
word
and
card fleld
.Elementaccess may
be followed by a name, index or range to select element(s)
from the collection. Properties access distributes over col-
lections; the following expression represents a a collection
of10 text style properties:
the textStyle of character 1 to 10
of card fleld "Description"
HyperCard has a built-in set of property and collection
names.
Eachobjecthas ascriptcontainingproceduresdefined for
that object. If the procedure name is aneventname,then the
procedure is ahandler for that event—it is called when the
event occurs forthat object.Forexample,abuttonscript may
have handlers for
mouseDown
,
mouseUp
and
mouseMove
events. The following handler shows the next card when a
button is released.
on mouseUp
go to next card
end mouseUp
Actions can be performed on chunk expressions to mod-
ify the stack, its cards, the objects, or their properties. For
example, clicking a button may run a script that moves to
the next card, adds/removes cards, or modifies the contents
of one or more cards. HyperCard has a set of predefined ac-
tions, including
set
,
go
,
add
,
close
,etc. For example, the
text style can be updated to a predefined constant
bold
:
set the textStyle of character 1 to 10
of card fleld "Description" to bold
HyperCard 2.0 was released in 1990. HyperCard was
very influential and widely used. Developers could easily
create some applications in HyperCard, but to create more
complex applications, they had to switch to more difficult
general-purpose developmenttools.The needfor unification
of these approaches was recognized early at Apple, leading
to the formation of a research and development project to
build a new development platform for the Mac, discussed
in the next section. Looking forward, the rapid develop-
ment capabilities pioneered by HyperCard were added to
more sophisticated general-purpose development environ-
ments. This gradually reduced the need for systems like Hy-
perCard, which was discontinued in 2004.
2.2 Family Farm
Many of the ideas that eventually emerged in AppleScript
were initially explored as part of a research project code-
named FamilyFarm,which was undertaken in the Advanced
TechnologyGroup (ATG) atApple,starting in1989.The re-
search teamwas led byLarry Teslerandincluded Mike Farr,
Mitchell Gass,Mike Gough,Jed Harris, Al Hoffman, Ruben
Kleiman, Edmund Lai, and Frank Ludolph. Larry received
aB.S. in Mathematics from Stanford University in 1965. In
1963, he founded and ran IPC, one of the first software de-
velopment firms in Palo Alto, CA. From 1968-73, he did
research at the Stanford A.I. Lab on cognitive modeling and
natural language understanding, where he designed and de-
velopedPUB,one ofthefirstmarkuplanguages withembed-
ded tags and scripting. From 1973-80, he was a researcher
at Xerox PARC, workingon object-oriented languages,user
interfaces, and desktop publishing.He joined Apple in 1980
1-4
application Library tool:VB.NET PDF Image Extract Library: Select, copy, paste PDF images
Image: Extract Image from PDF. |. Home ›› XDoc.PDF ›› VB.NET PDF: Extract PDF Image. VB.NET PDF - Extract Image from PDF Document in VB.NET.
www.rasteredge.com
application Library tool:VB.NET PDF Page Delete Library: remove PDF pages in vb.net, ASP.
doc.Save(outPutFilePath). How to VB.NET: Delete Consecutive Pages from PDF. doc.Save(outPutFilePath). How to VB.NET: Delete Specified Pages from PDF.
www.rasteredge.com
to work on the Lisa. In 1986, he was named director of Ad-
vanced Development,and in 1987,the first VP of Advanced
Technology,a new group focused on research.
The original goal of Family Farm was to create a new
integrated development environment for the Macintosh OS.
Family Farm included work on a new system-level pro-
gramming language, an interprocess communication model,
auser-level scripting language,and object component mod-
els,in addition to other areas.
The first AppleScript specification, which was the foun-
dation for later development, was written by the Family
Farm team. This document defined the basic approach to
generalizing HyperTalk chunk expressions to create Apple-
Script object-specifiers and Apple Events (described in de-
tail below). I believe credit for these ideas must be shared
equally by the Family Farm team, which generated many
ideas, and the teams which turned these ideas into usable
systems.
As a research project that grew quickly, the organization
put in place for Family Farm turned out not to be sufficient
to build and deliver commercial products. The team was
in the research group, not the system software group; No
changes to the Macintosh system could be shipped to cus-
tomers without approval of the system software group. And
if Family Farm did get approval, they would have to follow
the strictsoftwaredevelopment,scheduling,and qualitycon-
trol processes enforced by the system software group. Over
time itbecame clearthat the FamilyFarmteamwas also too
small to achieve its vision.
After about a year and a half of work, the Family Farm
projectwas disbanded,andnewteams werecreatedtodesign
and implement some of the concepts investigated by Family
Farm.
One ofthe mainthemes to emerge fromFamily Farmwas
afocus on techniques forintegrating applications. As men-
tioned in Section 1.2, integrating graphical applications can
be done at several levels: visual embedding, behavioral co-
ordination,ordata exchange.The spin-offprojects were Ap-
ple Events, AppleScript, and OpenDoc. The Apple Events
project, formed in mid-1990 from a subset of the Family
Farmteam,developed the underlying communication model
on which later projects were based. Later projects involved
larger teams that pulled key members from outside Fam-
ily Farm. AppleScript was next, then OpenDoc, both within
the Developer Tools Group at Apple. AppleScript focused
on data and behavioral integration. The OpenDoc project,
which is not discussed in detail here,focused on visual inte-
grationby embeddingcomponents.FamilyFarm’s transition
from researchto product development was a difficult one; in
the end the primary product transferred from Family Farm
to its descendants was an inspiring vision.
2.3 Apple Event Manager
The Apple Event Manager provides an inter-application
communication platform for the Macintosh.It was designed
with scripting in mind—however,the design was completed
before development of AppleScript began. When I started
at Apple in April 1991, my first job was to do a complete
code review of Apple Events, which was nearing the end of
its beta testing period. I sat in a conference room with Ed
Lai for over a week reading the code line by line and also
jumping around to check assumptions and review interre-
lationships. Ed was the primary developer of Apple Events
code. The system was written in Pascal, as was most of the
Macintosh system software of that era. The Apple Events
team was part of the Developer Tools group and was orig-
inally managed by Larry Tesler (who was also still VP in
ATG), but was latertaken over by Kurt Piersol.
In designing Apple Events, Kurt, Ed and the team had
to confront a serious limitation of the Macintosh OS: in
1990, the Macintosh OS could switch processes no more
than 60 times a second. If a process performed only a few
instructions before requesting a switch, the machine would
idle until 1/60th of a second had elapsed. A fine-grained
communication model, at the level of individual procedure
or method calls between remote objects, would be far too
slow: while a script within a single application could easily
call thousands of methods ina fraction ofa second, itwould
take several seconds to perform the same script if every
method call required a remote message and process switch.
As a result of this limitation of the OS, traditional remote
procedure calls (RPC)could not be used. Fine-grained RPC
was usedin CORBA and COM,whichwerebeingdeveloped
at the same time.
The Macintosh OS needed a communication model that
allowed objects in remote applications to be manipulated
without requiring many process round-trips. The Apple
Events communication model uses a generalization of Hy-
perCard’s chunk expressions. Justas a HyperCardcommand
contains a verb and one or more chunk expressions in its
predefinedinternallanguage,an Apple Eventcontains a verb
and a setofchunk expressions that refer to objects and prop-
erties in the target application. The generalized chunk ex-
pressions are calledobjectspecifiers . Apple Events address
the process-switching bottleneck by making it natural to
pack more behaviorinto a single message, thereby reducing
the need for communication round-trips between processes.
An Apple Event is in effect a small query/update program
that is formulated in one application andthen sentto another
application for interpretation.
Kurt Piersol and Mike Farrdebated whether there should
be few commands that could operate on many objects,
or a large number of specific commands as in traditional
command-line interfaces. For example, on Unix there are
different commands to delete print jobs (lprm), directories
(rmdir), and processes (kill). The analogy with verbs and
nouns in English helped Kurt win the argument for few
commands (verbs) that operate on general objects (nouns).
For example, in AppleScript there is a single
delete
com-
1-5
application Library tool:VB.NET PDF Page Insert Library: insert pages into PDF file in vb.
Page: Insert PDF Pages. |. Home ›› XDoc.PDF ›› VB.NET PDF: Insert PDF Page. Add and Insert Multiple PDF Pages to PDF Document Using VB.
www.rasteredge.com
application Library tool:C# PDF Page Delete Library: remove PDF pages in C#.net, ASP.NET
doc.Save(outPutFilePath); Demo Code: How to Delete Consecutive Pages from PDF in C#.NET. Demo Code: How to Delete Specified Pages from PDF in C#.NET.
www.rasteredge.com
Document
Paragraph
Word
Character
Size
Style
Size
Style
Size
Style
Name
Property
Element
A
B
A contains B
Key:
Root
Figure 1. Thepropertiesandelementsinasimpleobject
model.
mand that can delete paragraphs or characters from a word-
processing document, orfiles fromthe file system.Having a
small number of generic verbs, including
set
,
copy
,
delete
,
insert
,
open
and
close
,proved to be more extensible.
2.3.1 Object Specifiers
Object specifiers are symbolic references to objects in an
application. One application can create objectspecifiers that
refer to objects in another application, called the target.
The specifiers can then be included in an Apple Event and
sent to the target application. These symbolic references
are interpreted by the target application to locate the actual
remote objects. The target application then performs the
action specified by the verb in the Apple Event upon the
objects.
For example, a single Apple Event can be used to copy a
paragraph from one location to another in a document; the
source and targetlocationare included in the event as object
specifiers. The content of the paragraph remains local in the
target application. Traditional RPC models would require
the client to retrieve the paragraph contents, and then send
it back to the target as a separate insertion operation.
Object specifiers provide a view of application data that
includeselements andproperties. An element name repre-
sents a collection of values; a property has a single value.
The value of a property may be either a basic value, for ex-
ample an integer ora string, or another object. Elements are
always objects.
A simple object model is illustrated in Figure 1. A
document
has multiple
paragraph
elements and a
name
property. A paragraph has
style
and
size
properties and
contains
word
and
character
elements.
The distinction between properties and elements is re-
lated to theconceptofcardinality in entity-relationship mod-
eling[9]andUMLclass diagrams [32].Cardinality indicates
the maximum number of objects that may be involved in
a relationship. The most important distinction is between
single-valued (cardinality of 1) relationships and multi-
valued (cardinality greater than 1). The entity-relationship
model also includes attributes, which identify scalar, prim-
itive data values. An AppleScript property is used for both
attributes and single-valuedrelationships.Elements are used
to describe multivalued relationships.
The name identifying a set of elements is called aclass
name, identifying a specific kind of contained object and/or
its role. For example, a
Family
object might have elements
parents
and
children
, which are elements that refer to
sets of
Person
objects. Object specifiers allow application-
specific names forelements andproperties,which generalize
the fixed set of predefined names available in HyperCard.
Object specifiers also generalize HyperCard chunk ex-
pressions in other ways. One extension was the addition of
conditionstoselectelementsofacollectionbasedontheir
properties. This extension made object specifiers a form of
query language with significant expressive power.
Supporting Apple Events was frequently quite difficult.
Tocreate a new scriptable application,the software architect
mustdesign ascriptinginterface in addition tothe traditional
GUI interface. If the existing application architecture sepa-
rates views (graphical presentations) from models (underly-
ing information representation) [34], then adding scripting
is usually possible. In this case the internal methods on the
model may be exposedtoscripts.There are two reasons why
direct access to an existing object model may not be suffi-
cient:
1. Users often wantto control the userinterface of an appli-
cation, not just internal data of the application. Thus the
scriptinginterface should provide access toboth the view
objects and the model objects.
2. The interfaces of the internal object model may not be
suitable as an external scripting interface. In this case
the scripting interface is usually implemented to provide
another abstract view of the internal model.
Evenwith agood architecture,itcan be difficulttoretrofit
an existing GUI application to include a second interface
for scripting. If the application does not use a model-view
architecture, then adding scripting is much more difficult.
The Apple Events team created a support library to assist
application writers in interpreting object specifiers. It inter-
prets nesting and conditions in the object specifiers, while
using application callbacks to perform primitive property
and element operations.
2.3.2 Apple Events Implementation
Object specifiers are represented in Apple Events as nested
record structures, calleddescriptors[11]. Descriptors use a
self-describing, tagged tree data structured designed to be
easily transported orstored in a flattened binary format.De-
scriptors can either contain primitive data, a list of descrip-
tors,ora labeled productofdescriptors.Primitive data types
include numbers (small and large integers and floats), pic-
tures,styledandunstyled text,process IDs, files,andaliases.
All the structures, types, and record fields are identified by
1-6
four-byte type codes. These codes are chosen to be human-
readable to facilitate low-level debugging.
Eachkind of object specifier is a record withfields forthe
class, property name, index, and container. The container is
eitheranotherobjectspecifierrecordornull,representingthe
default or root container of the application. Events may be
sent synchronously or asynchronously. The default behavior
of Apple Events is stateless—the server does not maintain
state for each client session. However, Apple Events sup-
ports a simple form of transaction: multiple events can be
tagged with a transaction ID, which requires an application
to perform the events atomically or else signal an error.
Apple Events was first released with Macintosh System
7in 1991. The entire Apple Events system was designed,
implemented, and shipped in the Macintosh OS before any
products using it were built. It was a complex problem: ap-
plications could not be built until the infrastructure existed,
but the infrastructure could not be validated until many ap-
plications had used it. In the end, the Apple Events team
adopted a “build it and they will come”approach. They de-
signed the system as well as they could to meet predicted
needs.Only a fewsmall sample applications were developed
tovalidate the model. In addition, the operating systemteam
defined four standard events with a single simple parame-
ter: open application,open documents, print documents, and
quit.Thesefirstbasiceventsdidnot useobject specifiers; the
open and print events used a vector of path names as argu-
ments.
Laterprojects,includingAppleScript,hadtoworkaround
many of the Apple Events design choices that were made
essentially within a vacuum. For example, Apple Events
included some complex optimized message that were never
used because they were too unwieldy. For example, if an
array of values all has a common prefix, this prefix can be
defined once and omitted in each element of the array. This
was originally motivated by a desire to omit repetitive type
information. This optimization is not used by AppleScript
because itis difficultto detectwhenitcould beused,andthe
reduction in message length provided by the optimization
does not significantly affect performance.
3. The AppleScript Language
My primary task was to lead the design and implementation
of the AppleScript language. After I decided to join Apple
Imentioned the opportunity to Warren Harris. I enjoyed
workingwith Warren at HPand thought he wouldbe a great
addition to the AppleScript effort. Warren has a BS and
MS inree EE from the University of Kansas. At HP Warren
was still working on his “Abel Project Posthumous Report”,
which contained all the ideas we had discussed, but had not
time to complete, while working together at HP Labs [25].
Warren talked to Kurt and eventually decided to join the
AppleScriptteam as a softwareengineer.He quicklybecame
the co-architect and primary implementor of the language.
3.1 Requirements
AppleScript is intended to be used by all users of the Mac-
intosh OS.This does not imply that all users would use Ap-
pleScript to the same degree or in the same way—there is
clearly a wide range of sophistication in users of the Mac-
intosh OS, and many of them have no interest in, or need
for, learning even the simplest form of programming lan-
guage. However, these users couldinvoke scripts created by
other users, so there were important issues of packaging of
scripts, in addition to developing them. More sophisticated
users might be able torecord ormodifya script even if they
could not write it. Finally, it should be possible for non-
computer specialists towritescripts after some study.
The language was primarily aimed atcasual program-
mers, a group consisting of programmers from all experi-
ence levels. What distinguishes casual programming is that
it is infrequent and in service of some larger goal—the pro-
grammer is trying to get something else done, not create a
program. Even an experienced software developer can be a
casual programmer in AppleScript.
The team recognized that scripting is a form of program-
ming and requires more study and thought than using a
graphical interface. The team felt that the language should
be easy enough to learn and use to make it accessible to
non-programmers, and that such users would learn enough
programming as they went along to do the things that they
needed to do.
Programs were planned to be a few hundred lines long
at most, written by one programmer and maintained by a
series of programmers over widely spaced intervals. Scripts
embedded inside an application were also expected to be
small. In this case, the application provides the structure
to interconnect scripts; one script may send messages to
an application object that contains another script. Because
scripts are small, compilation speed was not a significant
concern. Readability was important because it was one way
to check that scripts did not contain malicious code.
In the early ’90s computer memory was still expensive
enough that code size was a significant issue, so the Ap-
pleScript compiler and execution engine needed to be as
small as possible. Portability was not an issue, since the lan-
guage was specifically designed for the Macintosh OS. Per-
formance of scripts within an application was not a signifi-
cant concern, because complex operations like image filter-
ing or database lookup would be performed by applications
running native code, not by scripts. Due to the high latency
ofprocess switches needed forcommunication,optimization
of communication costs was the priority.
3.2 Application Terminologies
Anapplicationterminology is a dictionary that defines the
names of all the events, properties, and elements supported
by an application. Aterminology can define names as plural
1-7
reference ::=
propertyName
j ‘beginning’
j ‘end’
j ‘before’ term
j ‘after’ term
j ‘some’ singularClass
j ‘ flrst ’ singularClass
j ‘last’ singularClass
j term (‘st’ j ‘nd’ j ‘rd’ j ‘th’) anyClass
j ‘middle’ anyClass
j plural [‘from’ term toOrThrough term]
j anyClass term [toOrThrough term]
j singularClass ‘before’ term
j singularClass ‘after’ term
j term (‘of’ j ‘in’ j ‘’s’) term
j term (‘whose’ j ‘where’ j ‘that’) term
plural ::= pluralClass j ‘every’ anyClass
toOrThrough ::= ‘to’ j ‘thru’ j ‘through’
call ::= message ‘(’ expr⁄ ‘)’
j
message [‘in’ j ‘of’] [term] arguments
j
term name arguments
message ::= name j terminologyMessage
arguments ::= ( preposition expression j °ag j record)⁄
°ag ::= (‘with’ j ‘without’) [name]+
record ::= ‘given’ (name ‘:’ expr)⁄
preposition ::=
‘to’ j ‘from’ j ‘thru’ j ‘through’
j ‘by’ j ‘on’ j ‘into’ j terminologyPreposition
Figure 2. AppleScriptgrammarforobjectreferences and
message sends.
or masculine/feminine, and this information can be used by
the customparser for a dialect.
One of the main functions of AppleScript is to send and
receive Apple Events (defined in Section 2.3). Sending an
Apple Event is analogous to an object-oriented message
send, while handling an Apple Event is done by defining a
method whose name is an Apple Event. One view of this
arrangement is that each application is an object that re-
sponds to a variety of messages containing complex argu-
ment types. AppleScript encourages a higher-level view in
which each application manages a set of objects to which
messages may be sent.
AppleScript also provides special syntax for manipulat-
ing Apple Event object specifiers, which are called “object
references”in AppleScript documentation. When an oper-
ation is performed on an object reference, an Apple Event
is created containing the appropriate verb and object spec-
ifier. Thus AppleScript needed to provide a concise syntax
forexpressing Apple Events.These AppleScript expressions
create object specifiers:
the flrst word of paragraph 22
name of every flgure of document ‘‘taxes ’’
the modiflcation date of every flle whose size > 1024
The first example is a reference to a particular word of a
paragraph. The second refers to the collection of names
associatedwithallfigures in adocumentnamed “taxes”.The
last one refers to the modification dates of large files.
For example, the object reference
name of window 1
identifies the name of the first window in an application.
Object references are like first-class pointers that can be
dereferenced or updated. An object reference is automati-
cally dereferenced when a primitive value is needed:
print the name of window 1
The primitive value associated with an object reference can
be updated:
set the name of window 1 to ‘‘Taxes’’
These examples illustrate that object specifiers can act as
both l-values and r-values.
Figure 2 includes the part of the AppleScript grammar
relatingto object specifiers. The grammar makes use of four
nonterminals that represent symbols from the application
terminology: for
property
,
singularClass
,
pluralClass
,
and
anyClass
.As mentioned in Section 2.3.1,a terminology
has properties and elements, which are identified by a class
name. Property names are identified by lexical analysis and
passed totheparser.For class names theterminologycan in-
cludebothpluralandsingularforms orageneric “any”form.
Forexample,
name
is a property,
window
is a singularclass,
and
windows
is a plural class. The grammar then accepts
windows from 1 to 10
and
every window from 1 to 10
,
Figure 2 also summarizes the syntax of messages. Argu-
ments can be given by position orname after the
given
key-
word. In addition, a set of standard prepositions can be used
as argument labels. This allows messages ofthe form:
copy paragraph 1 to end of document
The first parameter is
paragraph 1
, and the second argu-
ment is a prepositional argument named
to
with value
end of document
.
One of the most difficult aspects of the language design
arose from the fundamental ambiguity of object references:
an object reference is itself a first-class value,but it also de-
notes aparticularobject (orset ofobjects)withinan applica-
tion.Ina sense anobjectreference is like a symbolic pointer,
whichcanbe dereferencedto obtain its value;thereferenced
value can also be updated or assigned through the object
reference. The difficulties arose because of a desire to hide
the distinction between a reference and its value. The solu-
tion to this problem was to dereference them automatically
when necessary, and require special syntax to create an ob-
ject reference instead of accessing its value. The expression
a reference to o
creates a first-class reference to an object
1-8
described by
o
.Although the automatic dereferencing han-
dles most cases, a script can explicitly dereference
r
using
the expression
value of r
.The examples above can be ex-
pressed using a reference value:
set x to a reference to the name of window 1
The variable
x
can then be used in place of the original
reference. The following statements illustrate the effect of
operations involving
x
:
print the value of x
print x
set the value of x to ‘‘Taxes’’
set x to ‘‘Taxes’’
The first and second statements both print the name of the
window.In the first statement the dereference is explicit, but
in the second it happens implicitly because
print
expects a
string,nota reference.The third statementchanges the name
of the window, while the last one changes the values of the
variable
x
but leaves the window unchanged.
An object reference can be used as a base for further
object specifications.
set x to a reference to window 1
print the name of x
Figure 3 and 4 describe the custom terminology dictio-
nary for iChat,a chat,or instant messaging,program for the
Macintosh. It illustrates the use of classes,elements,proper-
ties, and customevents. Terminologies forlarge applications
are quite extensive: the Microsoft Word 2004 AppleScript
Reference is 529 pages long, andthe Adobe Photoshop CS2
AppleScript Scripting Reference is 251 pages. They each
have dozens of classes and hundreds of properties.
In addition to the terminology interpreted by individ-
ual applications, AppleScript has its own terminology to
identify applications on multiple machines. The expression
application ‘‘name’’
identifies an application.The expres-
sion
application ‘‘appName’’ of machine ‘‘machineName’’
refers to an application running on a specific machine. A
block of commands can be targeted at an application using
the
tell
statement:
tell application ‘‘ Excel ’’ on machine x
put 3.14 into cell 1 of row 2 of window 1
end
This is an example of a static
tell
command, because
the name of the target application is known statically, at
compile time. The target of the
tell
statement can also be
adynamic value rather than an application literal. In this
case the terminology is not loaded from the application. To
communicate with a dynamic application using a statically
specified terminology, a dynamic
tell
can be nested inside
astatic
tell
;the outer one sets the static terminology,while
the inner one defines the dynamic target. This brings up the
possibility that applications may receive messages that they
Class
application
:iChat application
Plural form:
applications
Elements:
account
,
service
,
window
,
document
Properties:
idle time
integer
Time in seconds that Ihave been idle.
image
picture
My image as it appears in all services.
status message
string
My status message, visible to other people
while Iam online.
status
string
My status on all services:
away/offline/available.
Class
service
:An instant-messaging service
Plural form:
services
Elements:
account
Properties:
status
string
The status of the service.:
disconnecting/connected/connecting/disconnected.
id
string
The unique id of the service.
name
string
The name of the service.
image
picture
The image for the service.
Class
account
:An accounton a service
Plural form:
accounts
Properties:
status
string
away/offline/available/idle/unknown.
id
string
The account’s service and handle. For ex-
ample: AIM:JohnDoe007.
handle
string
The account’s online name.
name
string
The account’s name as it appears in the
buddy list.
status message
The account’s status message.
capabilities
list
The account’s messagingcapabilities.
image
picture
The account’s custom image.
idle time
integer
The time in seconds the account has been
idle.
Figure 3. iChatSuite:ClassesintheiChatscriptingtermi-
nology [13].
1-9
Events
log inservice
Log in aservice withanaccount. Ifthe accountpassword
is not in the keychain the user will be prompted to enter
one.
log outservice
Logs out of a service,or all services if none is specified.
sendmessagetoaccount
Send account a text message or video invitation.
Figure 4. iChatSuite:EventsintheiChatscriptingtermi-
nology [13].
do not understand. In such situations,the application should
return an error.
Integration of multiple applications opens the possibility
that a single command may involve object references from
multiple applications.The target of a message is determined
by examining the arguments of the message. If all the argu-
ments are references to the same application,then that appli-
cation is the target. But if the arguments contain references
todifferentapplications,one oftheapplications mustbecho-
sen as the target. Since applications can interpret only their
own object specifiers, the other object references must be
evaluated to primitive values, which can then be sent to the
target application.
copy the name of the flrst window
of application "Excel"
to the end of the flrst paragraph
of app "Scriptable Text Editor"
This example illustrates copying between applications
without using the global clipboard. AppleScript picks the
target for an event by examining the first object reference in
the argument list. If the argument list contains references to
other applications, the values of the references are retrieved
andpassed in place of the references in the argument list.
Standard events and reference structures are defined in
theAppleEventRegistry. The Registry is divided into suites
that apply to domains of application. Suites contain spec-
ifications for classes and their properties, and events. Cur-
rently there are suites for core operations, textmanipulation,
databases, graphics,collaboration, and word services (spell-
checking, etc.).
Jon Pugh, with a BSCS from Western Washington Uni-
versity in 1983, was in charge of the Apple Events registry.
He also helped out with quality assurance and evangelism.
Since then he has worked on numerous scriptable applica-
tions,andcreated “Jon’s Commands,”a sharewarelibrary of
AppleScript extensions.
Terminologies also provide natural-language names for
the four-letter codes used within anApple Event.This meta-
data is storedinan application as a resource.As discussedin
Section 3.4 below, the terminology resources in an applica-
tion are used when parsing scripts targeting that application.
3.3 Programming Language Features
AppleScript’s programming language features include vari-
ables and assignment, control flow, and basic data struc-
tures. Control flow constructs include conditionals, a vari-
ety of looping constructs, subroutines, and exceptions.Sub-
routines allow positional, prepositional, and keyword para-
meters. Data structures include records, lists, and objects.
Destructuring bind, also known as pattern matching, can be
used to break apart basic data structures. Lists and records
are mutable. AppleScript also supports objects and a simple
transaction mechanism.
AppleScript has a simple object model. Ascriptobject
containspropertiesandmethods. Methods are dynamically
dispatched,soscriptobjects supporta simpleformof object-
oriented programming.The following simple script declara-
tionbinds the name
Counter
to anewscriptobjectrepresent-
ing a counter:
script Counter
property count : 0
to increment
set count to count + 1
return count
end increment
end script
Ascript declaration can be placed inside a method to
create multiple instances. Such a method is called a factory
method, and is similar to a constructor method in Java.
Since script can access any lexically enclosing variables, all
the objects created by a factory have access to the state of
the object that constructed them. The resulting pattern of
object references resembles the class/metaclass system in
Smalltalk [23], although in much simpler form.
AppleScript’s object model is a prototype model similar
to that employed by Self [37], as opposed to the container-
based inheritance model of HyperTalk. Script objects sup-
port single inheritance by delegating unhandled commands
to the value in their
parent
property [36]. JavaScript later
adopted a model similar to AppleScript.
The top level of every script is an implicit object decla-
ration.Top-level properties arepersistent, in that changes to
properties are saved when the application running the script
quits. A standalone script can be stored in a script file and
executed by opening it in the Finder. Such a script can di-
rect other applications to perform useful functions, but may
also call otherscript files. Thus, script files provide a simple
mechanism formodularity.
AppleScript provides no explicit support for threading or
synchronization. However, the application hosting a script
can invoke scripts from multiple threads: the execution
engine was thread-safe when run by the non-preemptive
scheduling in the original Macintosh OS.It is not safe when
1-10
Documents you may be interested
Documents you may be interested