Case 1:13-cv-00919-LPS Document 311-9 Filed 03/10/21 Page 1 of 144 PageID #: 29448
`Case 1:13-cv-00919—LPS Document 311-9 Filed 03/10/21 Page 1 of 144 PageID #: 29448
`
`EXHIBIT 64 PART 5
`
`EXHIBIT 64 PART 5
`
`

`

`Case 1:13-cv-00919-LPS Document 311-9 Filed 03/10/21 Page 2 of 144 PageID #: 29449
`
`CHAP TER 2 2
`
`Transport Interface
`
`Handling Requests When the Transport Is Active
`
`While the transport is actively sending or receiving data in the background, the user
`might request another send or receive operation from the In/Out Box. One way to
`handle such requests is to queue them up and append them to the current communi-
`cation transaction or to start another connection when the transport is finished.
`
`You can use the transport method QueueRequest to queue up requests for
`sending or receiving, if the transport already has an active communication session
`in progress. Call QueueRequest from the SendRequest or ReceiveRequest
`method, whichever one you receive as a result of a user request.
`
`Depending on how you call it, you can make QueueRequest append the new
`request to a request in progress or start another connection when the current
`request is finished. To append the new request to one in progress, for the first
`parameter, specify the request frame of a request already in progress. A request
`frame is the frame passed to SendRequest or ReceiveRequest to begin the
`request in progress. The second parameter is the new request frame.
`
`The following is an example of a SendRequest method in which
`QueueRequest is called to append the new request to the one in progress.
`
`// SendRequest method
`func (newRequest)
`begin
`if status <> 'idle then // check if I'm active
`// append to current request
`:QueueRequest(currentRequest, newRequest);
`else
`// do a normal send here
`end,
`
`When a new request is appended to an in-progress request, items from the new
`request are returned from the ItemRequest method after all items from the
`in-progress request are exhausted. In this way, new items are sent as part of the
`current communication session.
`
`To queue a new request so that the transport finishes its current transaction before
`beginning a new one, specify a symbol for the first parameter of QueueRequest.
`The symbol should be the name of a method that you want the system to call when
`the transport state returns to idle. Usually this is another SendRequest or
`ReceiveRequest method. The following is an example of a SendRequest
`method in which QueueRequest is called to defer a new request until the
`transport returns to the idle state.
`
`22-12
`
`Using the Transport Interface
`
`ARENDI-DEFS00004448
`
`

`

`Case 1:13-cv-00919-LPS Document 311-9 Filed 03/10/21 Page 3 of 144 PageID #: 29450
`
`CHAP TER 2 2
`
`Transport Interface
`
`// SendRequest method
`func (newRequest)
`begin
`if status <> 'idle then // check if I'm active
`// wait for idle and then call SendRequest again
`:QueueRequest('SendRequest, newRequest);
`else
`// do a normal send here
`end,
`
`Canceling an Operation
`
`The system sends the CancelRequest message to the transport when the user
`cancels the current transaction or for other reasons, such as when the system wants
`to turn off. This method must be defined by all transports.
`
`When a transport receives this message, it must terminate the communication
`operation as soon as possible.
`
`The CancelRequest method should return non-nil if it is OK to turn off power
`immediately after this method returns, or n 1 if it is not OK to turn off power
`immediately. In the latter case, the system waits until your transport returns to the
`idle state before turning off. This allows you to send an asynchronous cancel
`request to your communication endpoint, for example, and still return immediately
`from the CancelRequest method. When you receive the callback message from
`your endpoint cancel request confirming cancellation, use the SetstatusDialog
`method to set the transport status to idle to alert the system that it is OK to turn off.
`
`Obtaining an Item Frame
`
`The system sends the Newltem message to the transport to obtain a new item
`frame to make a new In/Out Box entry.
`
`This method is supplied by the protoTransport, but should be overridden by
`your transport to fill in extra values your transport uses. If you override this
`method, you must first call the inherited Newltem method, as shown in the
`example below. The item frame returned by the Newltem method should contain
`default values for your transport.
`
`The item frame returned by the default method supplied in protoTransport is
`not yet a soup entry. The item. category slot is initialized to the appSymbol
`slot in your transport. For more information on the item frame, see the section
`"Item Frame" beginning on page 22-2.
`
`The Newltem message is sent to your transport during both send and receive
`operations. When the user sends an item, the system sends the Newltem message
`to the transport to create a new In/Out Box entry before opening a routing slip
`
`Using the Transport Interface
`
`22-13
`
`ARENDI-DEFS00004449
`
`

`

`Case 1:13-cv-00919-LPS Document 311-9 Filed 03/10/21 Page 4 of 144 PageID #: 29451
`
`CHAP TER 2 2
`
`Transport Interface
`
`for the item. This allows the transport an opportunity to add its own slots to the
`item frame.
`
`Most transports will want to add a f romRe f slot to the item frame. This slot must
`contain a name reference that identifies the sender. This information is usually
`extracted from the sender's current owner card, or persona. You shouldn't just use
`the value of GetUserConfig ( ' currentPersona) because it is simply an alias
`to a names file entry. Instead, construct a name reference from this value. For example:
`
`persona
`dataDef
`fromRef
`
`GetUserConfig('currentPersona);
`GetDataDefs(addressingClass);
`dataDef:MakeNameRef(persona,addressingClass);
`
`Most transports will want to extract and send only the needed information from the
`f romRe f name reference. For example, an e-mail transport would typically just
`extract the sender name and e-mail address from the name reference and send them
`as strings. One method of name reference data definitions that you can use to
`extract useful information from a name card includes GetRoutingInfo. Here is
`an example of using this method:
`
`// extract just routing info using GetRoutingInfo
`routeInfo:= datadef:GetRoutingInfo(fromRef);
`// returns an array like this:
`[{name: "Chris Smith", email: "cbsmith@apple.test.com"}]
`
`The GetRoutingInfo method returns an array of at least one frame that has at
`least a name slot containing a string. Depending on the addressingClass slot
`passed to the GetDataDef s function, the returned frame also contains other
`information particular to the type of address used for the transport. In the example
`above, the frame also contains an emai 1 slot with an e-mail address.
`
`If you want to add other slots to the f romRe f frame, you can either define your
`own name reference data definition and override the method
`Get ItemRoutingFrame (called by GetRoutingInfo), or add the slots you
`want to the f romRe f frame by extracting them from the original name reference
`with the Get method. For example:
`
`// use Get to extract info from certain slots
`fromRef.myInfo := dataDef:Get(fromRef,'myInfo,nil);
`
`Note that a sender may have multiple e-mail addresses and the transport should set
`the e-mail address in the fromRef frame to the one that is appropriate to itself. For
`example, for an internet e-mail transport, you would typically set the f romRe f
`
`22-14
`
`Using the Transport Interface
`
`ARENDI-DEFS00004450
`
`

`

`Case 1:13-cv-00919-LPS Document 311-9 Filed 03/10/21 Page 5 of 144 PageID #: 29452
`
`CHAP TER 2 2
`
`Transport Interface
`
`e-mail address to the sender's internet address. Here's an example of code that sets
`the appropriate e-mail address in the fromRef object:
`
`owner:=ResolveEntryAlias(GetUserConfig('currentPersona));
`if owner and GetRoot().cardfile then begin
`addrs := GetRoot().cardfile:BcEmailAddress(owner,
`[' lstring.email.internetl ]);
`
`if addrs then
`fromRef := clone(addrs[0]);
`
`end
`
`You can find a description of BcEmailAddress and other similar functions that
`extract information from Names soup entries in "Names Functions and Methods"
`(page 16-5) in Newton Programmer's Reference.
`
`If, instead of extracting the address and sending it as a string, your transport sends
`addressing information as a frame, like the beam transport, you must remove any
`soup entry aliases from the name reference before it is transmitted. You can do
`this by using the name reference data definition method Prepare ForRouting,
`as follows:
`
`// strip the aliases from a name ref
`fromRef := datadef:PrepareForRouting(fromRef);
`
`In general, however, you should not send all the information in a user's persona
`with a message, since it can include personal or confidential information such as
`credit card numbers.
`
`For more information about name references and the methods of name reference
`data definitions, see the section "Creating a Name Reference" beginning on
`page 21-27, and "Name References" (page 5-1) in Newton Programmer's
`Reference.
`
`The following is an example of how to override the Newltem method during a
`send operation to add a f romRe f slot:
`
`// a sample overridden NewItem method
`mytransport.NewItem := func(context) begin
`// first call inherited method to get default frame
`local item := inherited:NewItem(context);
`
`// get sender info and insert fromRef slot
`local persona:= GetUserConfig('currentPersona);
`local dataDef := GetDataDefs(addressingClass);
`
`Using the Transport Interface
`
`22-15
`
`ARENDI-DEFS00004451
`
`

`

`Case 1:13-cv-00919-LPS Document 311-9 Filed 03/10/21 Page 6 of 144 PageID #: 29453
`
`CHAP TER 2 2
`
`Transport Interface
`
`if dataDef then
`begin
`item.fromRef := dataDef:MakeNameRef(persona,
`addressingClass);
`add other slots or extract routing info here
`end;
`item;
`end;
`
`During a receive operation, the transport itself must invoke the NewFromltem
`method to get a new In/Out Box item frame. This method copies most slots from
`the received item to the new In/Out Box item frame. Additionally, it inserts the
`destAppSymbol slot value (if included) in the received frame into the appsymbol
`slot in the new frame.
`
`Finally, the transport should call ItemCompleted to register the item in the In
`Box (see the following section).
`
`Completion and Logging
`
`After your transport finishes processing an item (either sending or receiving, with
`or without errors), you must send the transport the message ItemCompleted.
`This method must be used when an item is altered in any way. It performs several
`operations, including setting the state and error status of the item; sending the
`ItemCompletionscript callback message to the application; handling error
`conditions; and saving, logging, or deleting the item, depending on the logging
`preferences.
`
`Send the ItemCompleted message only after your transport has completely
`processed an item. If you send this message before you know that the item was
`delivered successfully, for example, there's a possibility that the item will be lost.
`
`If ItemCompleted was called as the result of an error, it calls HandleError to
`translate the error code and notify the user. If you want to perform your own error
`notification, you can override the HandleError method.
`
`Note that the ItemCompleted method in protoTransport sends the
`ItemCompletionscript callback message to the application only if the item
`contains a completionScript slot that is set to true. You must set this slot
`if you want the callback message to be sent. For more information on
`ItemCompletionScript see Newton Programmer's Reference (page 18-33).
`
`To perform logging, ItemCompleted sends your transport the message
`MakeLogEntry, passing a log entry to which you can add slots. The
`protoTransport object includes a default MakeLogEntry method, but you
`should override this method to add transport-specific slots to the log entry.
`
`The default method simply adds a t i t 1 e slot to the log entry. The
`GetItemTit1e transport method is called to get the title.
`
`22-16
`
`Using the Transport Interface
`
`ARENDI-DEFS00004452
`
`

`

`Case 1:13-cv-00919-LPS Document 311-9 Filed 03/10/21 Page 7 of 144 PageID #: 29454
`
`CHAP TER 2 2
`
`Transport Interface
`
`Storing Transport Preferences and Configuration Information
`
`Transports can store user-configurable preferences and other configuration
`information. Typically, you store several chunks of data that correspond to
`individual preferences or other kinds of configuration information that you want to
`save for your transport. You must use the transport methods GetConf ig and
`SetConf ig to retrieve and set configuration information for your transport.
`
`Default preferences for atransport are set by the defaultConfiguration slot
`in the transport object. This slot holds a frame containing values that correspond to
`items in a preferences slip that lets the user set preferences for your transport. For
`more information about displaying a preferences slip to the user, see the section
`"Providing a Preferences Template" beginning on page 22-33.
`
`If you don't want to use this preferences dialog or the setting of the
`defaultConfiguration slot in protoTransport, override the initial
`setting by creating your own default preferences frame and including it in the
`defaultConf iguration slot of your transport object. Note that you can't
`use a _proto slot in the default frame since the contents of the
`defaultConfiguration slot are stored in a soup and _proto slots can't be
`stored in soup entries.
`
`Extending the In/Out Box Interface
`
`Your transport can extend the In/Out Box interface if items the transport handles
`can be viewed in the In/Out Box. You can add additional actions to the In/Out Box
`Tag picker in the In/Out Box. The In/Out Box Tag picker is displayed when the
`user taps the Tag button in the In/Out Box, as shown here:
`
`In/Out Box
`Tag picker —
`
`Put Away
`Log
`Reply
`Forward
`
`Tag button
`
`The In/Out Box Tag picker includes only the Put Away and Log items by default.
`You can add other transport-dependent items by implementing the
`GetTransportscripts method. For example, the picker shown above includes
`Reply and Forward items added by an e-mail transport to let the user perform those
`operations on e-mail directly in the In/Out Box.
`
`When the user taps the Tag button, the system sends your transport the
`GetTransportscripts message, if you've implemented it. This method must
`return an array of frames that describe new items to be added to the In/Out Box Tag
`picker. The array is exactly the same as the routescripts array that adds items
`
`Using the Transport Interface
`
`22-17
`
`ARENDI-DEFS00004453
`
`

`

`Case 1:13-cv-00919-LPS Document 311-9 Filed 03/10/21 Page 8 of 144 PageID #: 29455
`
`CHAP TER 2 2
`
`Transport Interface
`
`to the Action picker in an application. Here is an example of a return value that
`adds two items to the picker:
`
`end,
`
`end,
`
`[ {title: "Reply", // name of action
`icon: ROM_RouteReply, // picker icon
`// called if action selected
`RouteScript: func(target, targetView) begin
`
`} {
`
`title: "Forward", // name of action
`icon: ROM_RouteForward, // picker icon
`// called if action selected
`RouteScript: func(target, targetView) begin
`
`} ]
`
`The RouteScript slot contains a method that is called if the user selects that
`item from the picker. Alternatively, in the RouteScript slot you can specify a
`symbol identifying a transport method, and then supply your transport symbol in
`another slot named appSymbol.
`
`For more detailed information about the items in the array, see the section
`"Providing Application-Specific Routing Actions" beginning on page 21-22.
`
`For the icon slot of each frame in the array, you can specify an icon that appears
`next to the name of the action in the picker. There are standard bitmaps available in
`the ROM for the following actions:
`n reply, ROM_RouteReply
`n forward, ROM RouteForward
`n add sender to the Names application, ROM_RouteAddsender
`n copy text to Notes application, ROM_RoutePasteText
`If you are adding one of these actions, use the indicated magic pointer constant for
`the standard bitmap, to keep the interface consistent among transports.
`
`Also, when the user taps the Tag button, the system sends your transport the
`CanPutAway message, if you've implemented it. This method allows your
`transport to add a put away option for the item to the Put Away picker. This hook
`allows a transport to put away items that could not otherwise be put away.
`Remember that applications (or transports) that need to put away items must
`implement the PutAwayscript method.
`
`Whenever an item belonging to your transport is displayed in the In/Out Box, the
`In/Out Box also sends your transport the IOBoxExtensions message. This hook
`lets your transport add functionality to items in the In/Out Box by adding to the list
`of view definitions available for an item.
`
`22-18
`
`Using the Transport Interface
`
`ARENDI-DEFS00004454
`
`

`

`Case 1:13-cv-00919-LPS Document 311-9 Filed 03/10/21 Page 9 of 144 PageID #: 29456
`
`CHAP TER 2 2
`
`Transport Interface
`
`Application Messages
`
`Applications can send messages directly to a single transport or to all transports by
`using the TransportNotify global function. This mechanism serves as a
`general way for applications to communicate with transports. Here is an example
`of using this function:
`
`TransportNotify(' all,'AppOpened,[appSymbol])
`
`The In/Out Box uses this mechanism to send three different messages to transports:
`AppOpened, AppClosed, and AppInFront. The AppOpened message notifies
`the transport that an application has opened and is interested in data from the
`transport. The In/Out Box sends this message to all transports when it opens. This
`method is not defined by default in protoTransport since it's transport-specific.
`If you want to respond to the AppOpened message, you must define this method in
`your transport.
`
`This message is designed to support applications that might poll for data, such as a
`pager. For example, when the application is open, it can notify the transport with
`this message so that the transport can poll more frequently (and use more power)
`than when the application is closed. Another use might be for an application to
`notify a transport that automatically makes a connection whenever the application
`is open.
`
`The AppClosed message notifies the transport that an application has closed. The
`In/Out Box sends this message to all transports when it closes. Again, this method
`is not defined by default in protoTransport since there is no default action—
`it's transport-specific. If you want to respond to the AppClosed message, you
`must define this method in your transport.
`
`Note that more than one application can be open at a time in the system. If you
`want your transport to do something like disconnect when it receives this message,
`keep track of how many times it's received the AppOpened message and don't
`actually disconnect until it receives the same number of AppClosed messages.
`
`The AppInFront message notifies the transport of a change in the frontmost
`status of an application—either the application is no longer frontmost, or it now is.
`The In/Out Box sends this message to all transports when another application is
`opened in front of the In/Out Box view, or when the In/Out Box view is brought to
`the front. Note that the AppInFront message is not sent when an application is
`opened or closed, so you need to check for the Appopened and AppClosed
`messages to catch those occurrences.
`
`Again, this method is not defined by default in protoTransport since there is
`no default action—it's transport-specific. If you want to respond to theAppinFront
`message, you must define this method in your transport. Not that this method is
`used only in special circumstances and is not needed by most transports.
`
`Using the Transport Interface
`
`22-19
`
`ARENDI-DEFS00004455
`
`

`

`Case 1:13-cv-00919-LPS Document 311-9 Filed 03/10/21 Page 10 of 144 PageID #: 29457
`
`CHAP TER 2 2
`
`Transport Interface
`
`Error Handling
`
`The default exception handling method implemented by protoTransport is
`HandleThrow, which catches and handles exceptions resulting from any supplied
`transport methods such as SendRequest and ReceiveRequest. You must
`provide your own exception handler for any methods that you define, or you can
`pass them to HandleThrow, as follows:
`
`try begin
`... // do something
`Throw () ;
`onException levt.exl do
`:HandleThrow();
`
`end
`
`When handling an exception, HandleThrow first calls IgnoreError to give
`your transport a chance to screen out benign errors. If IgnoreError returns
`true, Handl eThrow returns nil and stops.
`
`Assuming the error is not rejected by IgnoreError, HandleThrow next checks
`to see if an item is currently being processed. If so, it sends your transport the
`ItemCompleted message and returns true. Note that ItemCompleted calls
`HandleError to display an error alert to the user. If no item is currently being
`processed, HandleThrow sends the HandleError message itself to display an
`error alert.
`
`The HandleError method calls TranslateError to give your transport a
`chance to translate an error code into an error message that can be displayed to the
`user. If your transport can't translate the error (for example, because it's a
`system-defined error) you should simply call the inherited TranslateError
`method, which handles system-defined errors.
`
`Power-Off Handling
`
`The protoTransport object registers a power-off handler with the system
`whenever the transport is not in the idle state. If the system is about to power off,
`this power-off handler sends the transport the PowerOf f Check message.
`
`The default PoweroffCheck method in protoTransport displays a slip
`asking the user to confirm that it is OK to break the connection. Then, when the
`power is about to be turned off, the system sends the transport the
`CancelRequest message and waits until the transport is idle before turning the
`power off.
`
`You can override the default PowerOf (Check method if you wish.
`
`There is also apower-on handler that sends a CancelRequest message to the
`transport when the system turns on after shutting down unexpectedly while
`the transport is active.
`
`22-20
`
`Using the Transport Interface
`
`ARENDI-DEFS00004456
`
`

`

`Case 1:13-cv-00919-LPS Document 311-9 Filed 03/10/21 Page 11 of 144 PageID #: 29458
`
`CHAP TER 2 2
`
`Transport Interface
`
`Providing a Status Template
`
`A status template for a transport is based on the proto protostatusTemplate.
`The status template displays status information to the user. A transport should
`generally display a status view whenever it is sent the ReceiveRequest or
`SendRequest messages.
`
`You probably won't need to create your own status template. The protoTransport
`is defined with a default status template named statusTemplate (based on
`protostatusTemplate), which includes six predefined subtypes, described in
`Table 22-1 and shown in Figure 22-1. Each subtype consists of a set of child views
`that are added to the base status view. The base status view includes a transport
`icon and a close box, to which different child views are added, depending on the
`specified subtype name.
`
`Table 22-1
`
`Status view subtypes
`
`Subtype name
`
`vStatus
`
`Important values
`statusText (top string)
`
`vStatusTitle
`
`vConfirm
`
`vProgress
`
`vGauge
`
`vBarber
`
`statusText (top string),
`titleText (lower string)
`
`statusText (top string),
`primary (lower-button text
`and method: { text :
`string, script:
`function}), secondary
`(upper-button text and
`method: { text : string,
`script: functionD
`
`statusText (top string),
`titleText (lower string),
`progress (integer,
`percentage completed)
`statusText (top string),
`titleText (lower string),
`gauge (integer, percentage
`completed)
`statusText (top string),
`titleText (lower string),
`barber (set to true)
`
`Description
`A view that incorporates a status line.
`This is the default subview created by
`SetStatusDialog.
`
`A view that incorporates a status line and
`a line for the item's title.
`A view that has space for three lines of
`text, and two buttons. This view is
`suitable for situations where the user
`must choose between two options.
`
`A view that incorporates status and title
`lines, as well as a dog-eared page image
`that fills from top to bottom, based on the
`progress of the transfer.
`A view that incorporates status and title
`lines, as well as a horizontal gauge that
`fills from left to right, based on the
`progress of the transfer.
`A view that incorporates status and title
`lines, as well as a horizontal barber
`pole-like image that can be made to
`appear to move from left to right.
`
`Using the Transport Interface
`
`22-21
`
`ARENDI-DEFS00004457
`
`

`

`Case 1:13-cv-00919-LPS Document 311-9 Filed 03/10/21 Page 12 of 144 PageID #: 29459
`
`CHAP TER 2 2
`
`Transport Interface
`
`Figure 22-1
`
`Status view subtypes
`
`a Looking for host...
`
`vStatus
`
`Stop
`
`vStatusTitle
`
`a Connecting to host...
`
`I
`
`Data set 4
`
`Stop
`
`0
`
`vConfirm
`
`go The host has a new data
`4~1'
`set for you_ Do you want
`to receive it now?
`
`Receive Data Set
`
`Disconnect Now
`
`mQ Sending data set___
`
`vProgress
`
`Data set 4
`
`Stop
`
`I
`
`a Sending data set...
`
`vGauge
`
`Data set 4
`
`Stop
`
`9
`
`io Sending data set...
`
`vBarber
`
`Data set 4
`
`Stop
`
`Each child view included in a subtype has one important value that controls the
`appearance of that child element. For example, the vProgress subtype consists of
`three child views that have these important values: statusText (the string
`displayed at the top of the view), t i t 1 eText (the string displayed at the bottom of
`the view), and progress (an integer indicating the percentage of the page that
`should be shown filled with black). The important values for each subtype appear in
`Table 22-1. This information is necessary for use in the setstatusDialog method.
`
`A transport specifies the use of a subtype in the status view by passing the subtype
`name in the name parameter to the SetStatusDialog transport method.
`Transports can dynamically switch from one status subtype to another without
`closing the status view, and can easily update the contents of the status view as well
`(for example, updating the progress indicator).
`
`22-22
`
`Using the Transport Interface
`
`ARENDI-DEFS00004458
`
`

`

`Case 1:13-cv-00919-LPS Document 311-9 Filed 03/10/21 Page 13 of 144 PageID #: 29460
`
`CHAP TER 2 2
`
`Transport Interface
`
`Using this set of predefined status templates gives all transports a similar user
`interface and matches the use of other status views throughout the system.
`
`For more detailed information on protostatusTemplate and the predefined
`subtypes, refer to Chapter 17, "Additional System Services."
`
`Controlling the Status View
`
`Your transport should display a status view to the user whenever it is engaged in
`a lengthy activity such as sending or receiving data. In general, this means you
`must display a status view as part of the processing you do whenever you receive
`a SendRequest or ReceiveRequest message that results in the transmission
`of data.
`
`To display a status view, use the transport method SetstatusDialog. If the
`autostatus slot of the transport preferences frame is true, the status view
`opens automatically when you send the SetstatusDialog message with a
`status other than ' idle as the first parameter. If the status view is already open,
`SetstatusDialog updates the status view with the new status information you
`pass to it. If autostatus is nil, the status view does not open because the user
`has set a preference that it not be shown.
`
`Here is an example of how to use the SetstatusDialog method:
`
`:SetStatusDialog('Connecting, 'vStatus, "Looking for host...");
`
`The SetstatusDialog method takes three parameters. The first is a symbol
`indicating what the new transport status is. This is typically one of the slots in
`the dialogStatusMsgs frame, such as ' Connecting, or ' Idle. The
`second parameter is the name of the status subtype you want to use. You can
`specify one of the built-in subtypes described in the previous section, or the
`name of a custom subtype that you have constructed. (You specify the value of
`the name slot in the subtype template.) For information on constructing
`custom protoStatusTemplate view subtypes, see Chapter 17, "Additional
`System Services."
`
`The third parameter is typically a frame that contains one or more slots of values.
`Each slot corresponds to a single child view within the subtype you are using, and
`it sets the value of that child view. A slot name is the value of the name slot in the
`child view you are setting, and the value is whatever important value that type of
`view uses. The slot names and the expected values for the predefined status
`subtypes are listed in the "Important values" column in Table 22-1.
`
`The following examples show how you'd use the SetstatusDialog method to
`set the different status subtypes to create the status views shown in Figure 22-1.
`
`Using the Transport Interface
`
`22-23
`
`ARENDI-DEFS00004459
`
`

`

`Case 1:13-cv-00919-LPS Document 311-9 Filed 03/10/21 Page 14 of 144 PageID #: 29461
`
`CHAP TER 2 2
`
`Transport Interface
`
`// vStatus subtype
`:SetStatusDialog('Connecting, 'vStatus, "Looking for host...");
`
`// vStatusTitle subtype
`:SetStatusDialog('Connecting, 'vStatusTitle, {statusText: "Connecting
`to host...", titleText: "Data set 4 11 });
`
`// vConfirm subtype
`:SetStatusDialog('Confirming, 'vConfirm, {statusText: "The host has a
`new data set for you. Do you want to receive it now?",
`secondary:{text:"Receive Data Set", script: func() ... },
`primary:{text:"Disconnect Now", script: func() ... }});
`
`// vProgress subtype
`:SetStatusDialog('Sending, 'vProgress, {statusText: "Sending data
`set...", titleText: "Data set 4 11 , progress:40});
`
`// vGauge subtype
`:SetStatusDialog('Sending, 'vGauge, {statusText: "Sending data
`set...", titleText: "Data set 4 11 , gauge:40});
`
`// vBarber subtype
`:SetStatusDialog('Sending, 'vBarber, {statusText: "Sending data
`set...", titleText:"Data set 4 11 , barber:true});
`
`Once the status view is open, each time you call SetstatusDialog, the system
`closes and reopens all its child views. This is fairly fast, but if you just want to
`update aprogress indicator that is already visible in the subtypes vProgress,
`vGauge, or vBarber, you can use the alternate method Update Indicator.
`This protoStatusTemplate method updates the progress indicator child of the
`status view: the page image for the vProgress subtype, the horizontal bar for the
`vGauge subtype, and animation of the barber pole for the vBarber subtype.
`
`For example, you'd use Update Indicator to update the vGauge subtype
`as follows:
`statusDialog:UpdateIndicator({name:'vGauge, values:{gauge: 50,11);
`Note that the frame of data you pass to Update Indicator consists of two slots,
`name and values, that hold the name of the subtype and the value(s) you want to
`set, respectively. The values slot is specified just like the values parameter to
`SetstatusDialog.
`
`Also, note that Update Indicator is amethod of protoStatusTemplate,
`and you need to send this message to the open status view. A reference to the open
`status view is stored in the statusDialog slot of the transport frame, so you can
`send the message to the value of that slot, as shown above.
`
`22-24
`
`Using the Transport Interface
`
`ARENDI-DEFS00004460
`
`

`

`Case 1:13-cv-00919-LPS Document 311-9 Filed 03/10/21 Page 15 of 144 PageID #: 29462
`
`CHAP TER 2 2
`
`Transport Interface
`
`The vBarber subtype shows a barber pole-like image, but it doesn't animate
`automatically. To make it appear to move, use the Updatelndicator method in
`a Viewldlescript method, as shown here:
`
`// create the initial vBarber status view
`:SetStatusDialog('Sending, 'vBarber, {statusText: "Sending data
`set...", titleText:"Data set 1 11 , barber:true});
`
`// set up the status view data frame
`statusDialog.barberValueFrame:={name:'vBarber,values:{barber:true}};
`
`set up the idle script
`statusDialog.ViewIdleScript:= func()
`begin
`:UpdateIndicator(barberValueFrame); // spin the barber
`return 500; // idle for 0.5 seconds
`end;
`
`// start the idler
`statusDialog:Setupidle(500);
`
`If the autostatus slot of the transport preferences frame is true, the status
`view closes automatically when you send the SetstatusDialog message with
`' idle as the first parameter.
`
`You can force the status view to close manually by sending the transport the
`message ClosestatusDialog. However, the next time you send the message
`SetstatusDialog with a state other than ' idle as the first parameter, the
`dialog reopens.
`
`Providing a Routing Information Template
`
`When viewing an item in the In/Out Box, the user can tap the transport icon to the
`left of the item title to display a view that gives routing information about the item.
`For example, for a fax item, the fax phone number is displayed; for a mail item, the
`e-mail header is shown. Figure 22-2 (page 22-26) shows an