Using The AOCE Standard Mailer

Adding Standard Mailer support to MacWrite Pro

By Lee Richardson, Claris Corporation

About the author

Lee Richardson is the MacWrite Pro Project Manager at Claris, has been doing software in various forms for over ten years, and has been working for Claris way longer than he ever thought he’d work for any company. He’s available on AppleLink (RICHARDSON7) or CompuServe (74155,435).

Introduction

MacWrite Pro 1.0, from Claris Corporation, is the latest in a long line of products that started with the original MacWrite in 1984. MacWrite has gone through several revisions since then, with the current release offering a variety of high-end word processing and page layout features. MacWrite has always been known for its ease of use; MacWrite Pro continues that philosophy.

As part of the 1.5 release of MacWrite Pro, we’ve included support for Apple’s Open Collaboration Environment (AOCE) by adding Standard Mailer functionality. The Standard Mailer provides a high-level interface to AOCE, and includes automatic mailer drawing, mail addressing, catalog management, and support for enclosed files. By using the Standard Mailer, MacWrite Pro users can more easily share documents with others, and can stay in the same environment for both word processing and email tasks.

In this article, I’m going to describe the steps we went through to add Standard Mailer support to MacWrite Pro. I’ve also included sample code that shows how to read and write the different letter formats, and how to handle letters in both the mailbox and on disk.

Note: in the sample code, you’ll see the TRY/CATCH exception mechanism in use. This is an exception handler originally used in MacApp that simplifies error trapping (a similar scheme is used in C++). If an error occurs in the TRY block, execution is transferred to the first instruction in the CATCH block, then optionally back to the CATCH block in the caller. It’s a handy way to handle errors, but doesn’t otherwise affect the Standard Mailer examples.

Document Format

When we started working out the details of adding Standard Mailer support to MacWrite Pro, the first decision we ran into concerned how letters were to be represented in memory. It initially appeared that letters might be very different document types, and would need their own document format and saving code. But it eventually turned out that there were mostly similarities, and that our existing document structure, with a couple of additions, would suffice. Those additions consisted of flags for whether the document had a mailer, if the mailer was expanded or contracted, whether the mailer or the document was the current target, and the current height of the mailer, in pixels. We also added a LetterDescriptor (described later) giving the current location of the letter.

Adding a Mailer

Let’s start with a definition: a mailer is the addressing block that appears at the top of mail capable documents. It includes information about who the letter is from, who to send it to, the subject of the letter, and a list of enclosed files. Apple recommends that the mailer appear at the top of the document, just under the title bar, which is where we put it (we also considered a separate floating window, but decided the mailer information would be more clearly associated with the document if it was part of the document window).

The Mailer in a MacWrite Pro Document

You create a mailer and attach it to a document with the SMPAddMailer() routine. You specify a document window the mailer belongs to, various setup preferences, and an optional drawing callback routine. We use the callback to set the window origin correctly for the mailer, then set the origin to a different value for drawing the rest of the document. SMPAddMailer() doesn’t draw anything, but merely creates a mailer and associates it with a particular document.

One potential gotcha when you add a mailer has to do with scroll bars. The mailer contains two scroll bars - one each for the Recipients and Enclosures lists. These are added to the control list of the window when you call SMPAddMailer() (or any of the other routines that open a letter). If you already have controls in that list, and locate them by absolute position (like we used to), you’ll get some pretty strange results when you start scrolling and updating your window (there was a short period during our development when clicking on the vertical scroller actually moved the whole document to the left). A couple of solutions are to locate your controls by name, or save duplicates of the ControlHandles somewhere else.

Drawing Mailers

Most of the work in drawing a mailer in the MacWrite Pro document window involved moving all the window elements down and out of the way. In our case, the window contents all assume an upper left origin of (0,0), so it was a straightforward process to patch the origin-setting code to back up the height of the mailer and open up space at the top of the window. For example, if the mailer is currently 20 pixels high, we’ll set the origin to (-20, 0), then all the code that draws window elements starts drawing 20 pixels lower than usual. When we draw the mailer, the drawing callback resets the origin to (0,0) and the mailer happily draws itself right at the top.

Once you have a place for the mailer, you draw it by calling SMPDrawMailer(). We do specific updates when creating, deleting, or expanding the mailer, and on update events.

Event Handling

The documentation recommends sending all events directly from WaitNextEvent() to the Standard Mailer, via SMPDoMailEvent(), which we do. We then check the return code for any required actions on our part. This involves things like expanding or contracting the mailer, making either the mailer or document the current target (specifying which is hilighted and gets key events), and taking down any of our help balloons when the cursor is over the mailer.

Edit Menu

The Standard Mailer provides support for the basic Edit menu items when you’re in the mailer. This includes Cut/Copy/Paste of both subject text and addressing information, Select All/Clear for those same fields, and Undo for editing operations. You need to do your own menu tracking, and tell the mailer when anyone has selected any of those items. There’s also functionality within the mail code that provides a seamless match between undo within the mailer, and undo within your document window.

Letter Formats

The next section talks about sending a letter, but before we get into that, we need to discuss letter formats. A Standard Mailer letter is a document that can contain information in one or more formats. These formats are stored in blocks that are both written and read by Standard Mailer routines, so you never have to deal with them directly.

There are two standard mail formats: Standard Interchange, a styled text format that can include inline graphics, sounds, and movies, and Snapshot, which is a series of images of your document. Both of these formats can be read by the AppleMail application, which is included with System 7 Pro. If you include either of these formats in your letters, they can be read by anyone with a copy of AppleMail.

You can also create your own letter format, using the block structure of letters. This could be used to store a native version of your document, or any other data you want to include with the letter.

Finally, you can save a single document as the main enclosure of a letter. The document file is included in its entirety in the letter, but does not appear in the Enclosures list of the mailer. This is handy if you already have file saving code and don’t want to change it to use the letter block structure, and is the solution we use in MacWrite Pro for native formats.

Sending a Letter

Before doing anything, you need to check the letter to make sure it has both a subject and at least one recipient (see the routine Mail_SendSetup()). When that’s done, you put up the Send Options dialog with the SMPSendOptions() routine. This dialog, which is similar in usage to the Print dialog, lets the user select which formats to use, a high/medium/low letter priority, and whether to sign the letter with a digital signature. You control which formats are displayed, both for the standard formats and your own, and you can create a list if you have more than one. MacWrite Pro uses this latter capability to provide a list of XTND translators that can be used for letter sending.

Once you have a format selection, you need to send the format(s) (see Mail_Send()). You start the send process by calling SMPBeginSend(), write out each of the selected formats, then end the process with SMPEndSend(). SMPBeginSend() will check to make sure you actually need to write content (you may be forwarding a letter that hasn’t been changed, for example); SMPEndSend() closes the letter and sends it.

Native Formats

Sending your own native document, if you use the main enclosure scheme, is pretty easy: get an FSSpec for the Temporary Folder with FindFolder() and FSMakeFSSpec(), save your document there by doing a normal save, then hand the document off to the Standard Mailer with SMPAddMainEnclosure(). See the routine Mail_FailWriteDoc() for details.

Standard Interchange

Sending the Standard Interchange format is a little more involved, but still straightforward. The general plan is to write your document content in blocks, which are contiguous chunks of similar data. There are blocks for styled text, PICTs, QuickTime movies, and sound (in AIFF format). Every time you change a block type, you’ll tell the Standard Mailer so it can keep track of which is which.

For example, let’s say you’re sending a one-page letter that has a half-page of text, an inline graphic in the center, followed by another half-page of text. The first block you write will be a styled text block, consisting of the first half-page of text. You’ll then write a PICT block for the graphic, then finish up with a third styled text block for the last half-page of text. The example fragment below illustrates how SMPAddContent() is used.

/* 1 */
Mail_GetContiguousText(theDoc, &textOffset, 
 textHdl, styleHdl);
SMPAddContent(theDoc, kMailStyledTextSegmentType, 
 kNewSegment, *textHdl, GetHandleSize(textHdl), 
 *styleHdl, kNewScript, smRoman);

Mail_GetPICT(theDoc, &textOffset, thePICT);
SMPAddContent(theDoc, kMailPictSegmentMask, kNewSegment, 
 *thePICT, GetHandleSize(thePICT), nil, kSameScript, 0);

Mail_GetContiguousText(theDoc, &textOffset, 
 textHdl, styleHdl);
SMPAddContent(theDoc, kMailStyledTextSegmentType, 
 kNewSegment, *textHdl, textLength, *styleHdl, 
 kSameScript, smRoman);

kNewSegment is my constant that equals FALSE and says that we aren’t appending the same content type as the previous SMPAddContent() call. You’d use TRUE here if you were adding several styled text blocks in a row. kNewScript equals TRUE and shows that we’re starting a new script block. kSameScript is FALSE and is used as long as you remain in the same script system.

Since the text block formats are the same as styled text scrap formats, we were able to use the MacWrite Pro code that converts our internal format to external scrap formats to generate the letter block information (in essence, copying and pasting our way through the document and into the letter).

Snapshot

An advantage of sending a letter using the Standard Interchange format is that the recipient of your letter gets editable text. A disadvantage, though, is that you can lose information in the process (MacWrite Pro, for example, doesn’t include the contents of headers or footers, or any floating text frames or tables you might have). You may also have a document type that doesn’t lend itself well to Standard Interchange (like a drawing or database application). Snapshot format is a way to send your document as a set of images, which appear exactly as seen on screen or on the printer.

To send a letter in Snapshot format, you call SMPImage() to set up the drawing environment, and include a callback routine that does the actual imaging. This callback routine draws the cover pages, which provide the addressing information showing in the mailer(s), then steps through each page in your document and draws it to the current port as set up by SMPImage(). See the example routines Mail_FailWriteSnapshot() and Mail_DrawPages() for more details.

Saving a Letter

Saving a letter on disk is almost exactly the same as sending it, except that you choose the formats that are saved. We include a MacWrite Pro main enclosure document as the richest form of the content, and do Standard Interchange format so that anyone can read the letter with AppleMail. We use our own creator and file types, and our own icon.

A potential confusion involving letters saved through the Standard Mailer is that you can’t read them if AOCE is not present. Since the letter is saved using the Standard Mailer block format (or using the Standard Mailer main enclosure), there’s no way to retrieve the information without it. We deal with this in MacWrite Pro 1.5 by putting up an alert if someone attempts to open a letter on a system that doesn’t have AOCE installed.

Opening Letters

A letter can exist either on disk or in the PowerTalk mailbox (the In Tray). If it’s on disk, it’s treated as a regular file, and can be opened through a regular SFGetFile call or by an ‘odoc’ AppleEvent. This would be pretty standard, except that AOCE identifies letter documents with a special Finder flag. This flag (0x0200, the former ‘changed’ bit) shows that an incoming document is a letter and may contain one of the standard formats (using a Finder flag makes it possible to use different file types, yet still identify a document as a letter). If you support either Standard Interchange or Snapshot formats, you should check that bit in any incoming documents with GetFInfo(), then open the document regardless of its file type.

If a letter is in the mailbox, you won’t be able to see it in the standard file dialog, so the only way to open it is by double-clicking it. This also generates an ‘odoc’ event, except that instead of getting an FSSpec in the event, you’ll get a LetterSpec, which is a structure unique to letters in the mailbox. The Standard Mailer provides a LetterDescriptor data structure that handles both of these cases:

/* 2 */

struct LetterDescriptor {
 BooleanonDisk;
 union {
 FSSpec fileSpec;
 LetterSpec mailboxSpec;
 }u;
};

The only unclear aspect of this process is that you have to set it up yourself, based on the event you get. See the sample routine Mail_DoOpenDoc() to see how it works.

Reading a Letter

Opening and reading the contents of a letter reverses the send or save process, except that you don’t know what’s there until you look. We go through the following steps:

1) Is there a main enclosure? If so, get it and see if we can open it, either as a native doc or using XTND

2) If no main enclosure, or we can’t read what’s there, are there any any standard interchange blocks? If so, read them.

3) No doc yet? Look for image blocks and read them.

4) Still no doc? Create an empty one so the user can get to any enclosures that might be attached.

We initially attempted to let the user know if there were no readable formats in the letter. However, an empty document looks the same as a document with no readable formats, so we just open an empty letter if there’s nothing there.

There are a couple of inelegant sides to opening letters. The first one is that letters (mailers) are always attached to windows. For example, when you open a letter with SMPOpenLetter(), the first parameter is a LetterDescriptor, and the second is the doc window you’re going to display the letter in. However, in MacWrite Pro we don’t have a doc window yet, and won’t until we either open the main enclosure, or create a doc for one of the other formats. I tried using our clipboard window as a temporary window, but ran into a performance problem with opening the letter twice (AOCE is not fast), and had a more fundamental problem with the kSMPCopyInProgress error described below. I ended up creating my own doc window for opening the letter, then patching the rest of the application to use that window when creating or opening a document. Tacky, but it worked.

The other problem you’ll potentially run into has to do with error recovery during your open. If you open the letter, then run out of memory later in the process, you’ll probably want to close the letter and dispose of that window. However, the SMPPrepareToClose() routine will somewhat sporadically return a kSMPCopyInProgress error when you attempt to close it. Bad juju. According to MacDTS, this has something to do with the open event not having completed yet and therefore not clearing that flag. What it means is that you have to keep that window around until the Standard Mailer will let you close it. The best way is to check the window somewhere in the main event loop, then close and dispose of it when SMPPrepareToClose() finally comes back with noErr. (If anyone else has a better solution, please let me know.)

A simplified version of opening letters is shown in the routine Mail_OpenLetter().

Reading Main Enclosures

This is easy. Once you’ve opened the letter, look for the main enclosure with SMPGetMainEnclosureFSSpec(). If you get a fileSpec back, you can do whatever is necessary to open it (or avoid opening it, if it’s not in a format you recognize).

Reading Standard Interchange

The pertinent routine here is SMPReadContent(). You step through all the standard interchange blocks, which again can be text, styled text, PICTs, movies, or sounds, read each one in, figure out what you have, then drop it into your document. In MacWrite Pro, this is the opposite process from writing this format out, in that we essentially get successive scrap elements from SMPReadContent() and paste them into the main body of the document.

Reading Snapshots

This is a little more interesting. When you created the snapshot, the Standard Mailer saved each imaged page as a separate PICT, the same size as your page, into one or more image blocks. Each image block starts with a TPfPgDir struct, which tells you how many pages there are in that block, and the offset of each PICT that describes that page. You use SMPReadBlock() at the start of each block to retrieve the struct, then loop through each of the pages and read the PICT from the specified offset using the specified length (also using SMPReadBlock()). When you get to the end of the pages, you read the next block. When you get a kIPMBlkNotFound error, you’re done.

The fun part of this format is that you get a bunch of page-size pictures of the original document, which you then have to figure out what to do with. We ended up sizing the document margins to match the first PICT, then pasting each picture into successive pages as inline graphics. There’s something pleasantly twisted about a word processing document that looks like a real doc, has text like a real doc, but is really just pictures masquerading as a document (sort of like the plastic food you’ll see in the windows of Japanese restaurants). See the sample routine Mail_FailReadImage() for the gory details.

Reply and Forward

Once you’ve opened a letter, you may want to reply to it. Recommended practice is to give the user a choice between Reply to Sender and Reply to All, which you can either do through two separate menu items or as a dialog with a couple of radio buttons; we chose the latter. To create the reply, we make a new document, copy the original text into it with a header at the top (showing who wrote the original and when), then turn that document into a reply with the SMPMailerReply() routine. SMPMailerReply() uses the addressing information from the original to set up the mailer attached to the reply, and sets the recipient list using the answer from the earlier Reply to Sender/All question. After the reply is created, it’s treated like a regular letter, and can either be sent or saved as requested.

Forwarding a letter is trivial, and consists of a single call to SMPMailerForward(). This routine overlays another mailer over the existing topmost mailer, whereupon the user can address it and send it or save it.

Preferences

The final thing to think about is Mail Preferences. MacWrite Pro gives users the ability to specify whether mailers are expanded or collapsed when creating, opening, or replying to a letter, whether to include the original text in a reply, and, optionally, whether to style or color the original text. The AppleMail application does something similar.

Conclusion

That covers the basics of adding Standard Mailer support to a product. I found the process to be straightforward, once I got past my initial surprise at the quantity of routines in the Standard Mailer. With a couple of minor exceptions, dealing with the Standard Mailer has been quite pleasant - it does everything it says it does, and, so far, has done everything I need.

Other sources of information include the AOCE Application Interfaces manual from Apple and the Standard Mailer sample application CollaboDraw, included with the System 7 Pro developer’s kit. CollaboDraw is pretty handy for figuring out the overall structure of Standard Mailer support. You can also check out the AppleMail application, automatically included with System 7 Pro, for mailer handling, preferences, and other usage items.

In closing, I’d like to thank Scott Lindsey at Claris for giving help above and beyond the call of duty during my Standard Mailer implementation, both for information provided and code graciously explained.

/* 3 */

// --------------------------------------------------------------
void Mail_Send(DocumentPtr theDoc)
{
 TRY
 {
 BooleanmustAddContent;
 OSType ltrCreator;
 short  okToSend = true;
 SMPSendOptions  sendOptions;
 SMPSendFormat   sendFormat;

 FailFalse(Mail_SendSetup(theDoc, &sendFormat, 
 &sendOptions));
 if (sendFormat.whichFormats & kSMPNativeMask)
 // we're doing our native format, so make it our document
 ltrCreator = kMyCreatorType;
 else
 // if we're not including our native format, 
 // always make it an AppleMail doc
 ltrCreator = kAppleMailCreator;
 Mail_SetCursor(kWatchCursor);
 // start the sending process
 FailOSErr(SMPBeginSend((WindowPtr) theDoc, ltrCreator, 
 typeLetterSpec, &sendOptions, &mustAddContent));
 // if the Standard Mailer says the letter has changed
 // from the last version, rewrite the content
 if (mustAddContent)
 {
 TRY
 {
 if (sendFormat.whichFormats & kSMPNativeMask)
 Mail_FailWriteDoc(theDoc);
 if (sendFormat.whichFormats & kSMPImageMask)
 Mail_FailWriteSnapshot(theDoc);
 if (sendFormat.whichFormats & 
 kSMPStandardInterchangeMask)
 Mail_FailWriteStdInterchange(theDoc);
 }
 CATCH
 {
 // tell the mail system we’re cancelling
 okToSend = false;
 }
 ENDTRY
 }
 // we’re done
 FailOSErr(SMPEndSend((WindowPtr) theDoc, okToSend));
 }
 CATCH
 {
 Mail_SetError(THISERROR);
 }
 ENDTRY
 Mail_SetCursor(kArrowCursor);
} // end Mail_Send

// --------------------------------------------------------------
short Mail_SendSetup(DocumentPtr theDoc, 
 SMPSendFormat *sendFormat, SMPSendOptionsPtr sendOptions)
{
 unsigned short  subjectSize, toSize;
 OSErr  myErr = noErr;
 Str255 appName, docName;
 StringPtrappNamePtr[1] = appName;

 // make sure the letter has a subject
 SMPGetComponentSize((WindowPtr) theDoc, 1, kSMPRegarding, 
 &subjectSize);
 if (subjectSize <= offsetof(RString, body))
 {
 Mail_SetError(kOCENeedSubject);
 Mail_SetError(SMPBecomeTarget((WindowPtr) theDoc, true, 
 kSMPRegarding));
 Mail_MakeMailerTarget(theDoc);
 return false;
 }
 // also make sure the letter has at least one recipient
 SMPGetComponentSize((WindowPtr) theDoc, 1, kSMPTo, &toSize);
 if (!toSize)
 {
 Mail_SetError(kOCENeedRecipient);
 Mail_SetError(SMPBecomeTarget((WindowPtr) theDoc, true, 
 kSMPTo));
 Mail_MakeMailerTarget(theDoc);
 return false;
 }
 // get the app name for our native format
 GetIndString(appName, kInfoStrID, kAppNameItem);
 GetWTitle((WindowPtr) theDoc, docName);
 // do the options dialog. We’re only going to show
 // one native format, along with Snapshot and
 // Standard Interchange.
 myErr = SMPSendOptionsDialog((WindowPtr) theDoc, docName, 
 appNamePtr, 1, kSMPNativeMask + kSMPImageMask + 
 kSMPStandardInterchangeMask,
 sendFormat, nil, nil, sendFormat, sendOptions);
 if (myErr && myErr != userCanceledErr)
 Mail_SetError(myErr);
 return myErr ? false : true;
} // end Mail_SendSetup

// --------------------------------------------------------------
pascal void Mail_DrawPages(long refcon, Boolean inColor)
{
 #pragma unused(inColor)

 DocumentPtrtheDoc = (DocumentPtr) refcon;
 short  i;
 short  pageCount;
 OpenCPicParams  picHeader;

 // set everything in picHeader to 0, then set non-zero values
 Mail_ClearRecord(&picHeader, sizeof(picHeader));
 picHeader.srcRect.bottom = theDoc->pageLength;
 picHeader.srcRect.right  = theDoc->pageWidth;
 picHeader.hRes  = theDoc->hRes << 16;
 picHeader.vRes  = theDoc->vRes << 16;
 picHeader.version = -2;
 // draw the cover pages
 gMyErr = SMPPrepareCoverPages((WindowPtr) theDoc, &pageCount);
 for (i = 1; i <= pageCount && gMyErr == noErr; ++i)
 if (!(gMyErr = SMPNewPage(&picHeader)))
 gMyErr = SMPDrawNthCoverPage((WindowPtr) theDoc, i, 
 i == pageCount);
 // step through each page in the document and draw it
 for (i = 1; i <= theDoc->pageCount && gMyErr == noErr; ++i)
 if (!(gMyErr = SMPNewPage(&picHeader)))
 // do whatever's necessary to draw a document page
 gMyErr = Mail_DrawOnePage(theDoc, i);
} // end Mail_DrawPages

// --------------------------------------------------------------
OSErr Mail_OpenLetter(LetterDescriptor *letterDesc)
{
 volatile DocumentPtrtheDoc = nil;
 OSErr  myErr    = noErr;
 GrafPtroldPort;

 Mail_SetCursor(kWatchCursor);
 GetPort(&oldPort);
 TRY
 {
 FSSpec mainEncSpec;
 const PointtopLeft= {0, 0};
 const Rect boundsRect  = {0, 0, 120, 120};
 SMPMailerState  mailerState;
 short  mailerWidth;
 short  contractedHeight;
 short  expandedHeight;

 // do some memory preflighting
 FailWithErr(Mail_AvailableMem() < kMinToCreateDoc, 
 memFullErr);
 // this should not fail, after the above test. But 
 // let's check anyway.
 FailNull(theDoc =
 (DocumentPtr) NewPtr(sizeof(DocumentRecord)));
 // we create a ‘real’ document later, need WindowPtr now
 theDoc = (DocumentPtr) NewWindow(theDoc, &boundsRect, "\p", 
 false, documentProc, nil, true, 0);
 SetPort((WindowPtr) theDoc);
 BlockMove(letterDesc, &theDoc->theLetter, 
 sizeof(theDoc->theLetter));
 // open the letter. This is equivalent to adding a mailer.
 FailOSErr(SMPOpenLetter(&theDoc->theLetter, 
 (WindowPtr) theDoc, topLeft, kCanContract, true, 
 Mail_DrawingSetup, nil));
 theDoc->isMailer = true;
 // see if there’s a main enclosure file
 myErr = SMPGetMainEnclosureFSSpec((WindowPtr) theDoc, 
 &mainEncSpec);
 if (myErr == noErr)
 myErr = Mail_OpenDocument(&mainEncSpec);
 // fnfErr here either means there was no main enclosure,
 // or we couldn’t read it
 if (myErr == fnfErr)
 myErr = Mail_ReadStdInterchange(theDoc);
 if (myErr == fnfErr)
 myErr = Mail_ReadImage(theDoc);
 // if we couldn’t find anything, just do an empty letter.
 if (myErr == fnfErr)
 myErr = Mail_CreateNewDoc(theDoc);
 FailOSErr(myErr);
 FailOSErr(SMPGetMailerState((WindowPtr) theDoc, 
 &mailerState));
 if (theDoc->theLetter.onDisk)
 // the letter exists as a file on disk, so use the 
 // file name as the window title
 SetWTitle((WindowPtr) theDoc, 
 theDoc->theLetter.u.fileSpec.name);
 else
 {
 SMPLetterInfo letterInfo;
 
 // we're opening the doc from the In Tray, so use the
 // subject as the window title
 FailOSErr(SMPGetLetterInfo(
 &theDoc->theLetter.u.mailboxSpec, &letterInfo));
 SetWTitle((WindowPtr) theDoc, 
 OCERToPString((RStringPtr) &letterInfo.subject));
 }
 // get the mailer sizes, and save the pertinent one
 FailOSErr(SMPGetDimensions(&mailerWidth, &contractedHeight,
 &expandedHeight));
 theDoc->mailerHeight= mailerState.isExpanded ? 
 expandedHeight : contractedHeight;
 theDoc->mailerState = mailerState.isExpanded ? 
 kExpandedMailer : kContractedMailer;
 Mail_SetWindowSize(theDoc);
 // actually draw the window
 ShowWindow((WindowPtr) theDoc);
 }
 CATCH
 {
/* if we get an exception, we'll probably have a window to get rid of. That window 
will have a mailer, which we need to dispose. However, we probably can't dispose of 
the mailer yet, because of the silly kSMPCopyInProgress error. So take a shot at the 
mailer, and if it goes away, dispose of the window. But if it doesn't go away, save 
the window for later, and we'll dispose of it and the mailer in _DoEvent after we've 
gone through the event loop a time or two. See the article text for more information. 
*/
 if (theDoc && theDoc->isMailer)
 {
 OSErr closeErr;
 
 if (!(closeErr = SMPPrepareToClose((WindowPtr) theDoc)))
 closeErr = SMPDisposeMailer((WindowPtr) theDoc, nil);
 if (!closeErr)
 theDoc->isMailer = false;
 }
 if (theDoc)
 {
 if (!theDoc->isMailer)
 {
 Mail_DisposeNewDoc(theDoc);
 SetPort(oldPort);
 }
 else
 gDisposeThisDocument = theDoc;
 theDoc = nil;
 }
 
 Mail_SetError(myErr = THISERROR);
 }
 ENDTRY
 return myErr;
} // Mail_OpenLetter