Sprocket is Here!

Getting started requires getting in to gear!

By Dave Mark, MacTech Magazine Regular Contributing Author

In the last few columns, I told you about a new framework that was going to form the basis for much of the code written for this magazine. Well, as you can see from the title, Sprocket is here! Though Sprocket has existed in various incarnations for a while, I’ve only recently had the chance to really get into it. (I’ve been completely consumed with the goal of getting Ultimate Mac Programming out the door in time for January MacWorld).

This month, we’ll take a walk through the Sprocket architecture, focusing on the files and routines you’ll work with as you customize Sprocket to fit your needs.

Getting Sprocket

The first thing you’ll need to do is get a copy of the latest version of Sprocket. It’s included on the monthly MacTech source code disks and is archived at the usual online sites (which are listed every month on page 2).

Hopefully, by the time you read this, there will be versions of Sprocket for both Symantec C++ and Metrowerks CodeWarrior. As I write this, I’ve only got the CodeWarrior version, so bear with this unintended bias. Hopefully, there won’t be too many differences between the two versions.

As you get into Sprocket, it’s important to realize that we are at the beginning of a long evolutionary process. Sprocket was just born and there will no doubt be lots of design changes, bugs, and what have you. Here’s your chance to get in on the ground floor. If you find a bug, or have any specific comments about or feature requests for Sprocket, send a complete description to sprocket@hax.com.

The Sprocket Files

Open the Sprocket folder and launch the Sprocket project (mine was called SprocketSample.µ). You’ll notice that the files are organized into three different groups.

On the 680x0 side of the fence, each of these groups takes the form of a segment. On the PowerPC side, segments are a thing of the past, so the file groupings are more for aesthetics.

The first group of files is called Sprocket Code (see Figure 1), and is made up of the files that are private to Sprocket. These are the files that implement things like the event loop, the main base classes, the required Apple events, etc. For now, just ignore these files. As you get to know Sprocket and have a few Sprocket applications under your belt, you might want to explore these files and possibly tweak a few things to fit your specific needs.

The second group of files is labeled GX Graphics Libraries and contains routines you’ll need to work with Quickdraw GX. By the time you read this, the file(s) in this section may have been rolled in with the rest of the files in the Sprocket Code section.

The third group of files is labeled Application Specific. This is where you’ll put your code. As you’ll see, contained within the files in this section are a series of 9 routines that you must provide to make Sprocket run. These routines do things like perform application initialization, dispatch menu selections, and create new documents. Every Sprocket application has these routines, including the generic Sprocket application that came with Sprocket in the first place. Each time you create a new Sprocket application, you’ll duplicate the folder containing the application specific files, then edit the routines in those files as you see fit. At the very least, you’ll need to make sure that the 9 critical routines do what you need them to.

Figure 1. My Sprocket project file, as implemented by CodeWarrior.

A Quick Sprocket Test Drive

Before we get to them, let’s take Sprocket for a quick spin, just to get a feel for what it looks like. Once again, keep in mind the fact that I’m writing this in November and that things will undoubtedly change by the time you read this.

When you launch the generic Sprocket application, two new windows appear. The window on the left is a palette or tool window (Figure 2). It floats, meaning that it always appears in front of all other windows. Imagine this window filled with tool icons. When the user clicks on an icon, you’ll change the cursor to reflect the new tool and implement the tool’s behavior as the user clicks and drags in a document window.

Figure 2. The generic Sprocket tool window.

The other window that appears (Figure 3) is a document window, customized to include a nifty pair of spinning arrows in their own pane, a pair of horizontal lines that separate this pane from the main content region, and a pair of scroll bars. If you select New from the File menu, a new, untitled document window will appear. When you create your own sprocket applications, you’ll have complete control over the look and behavior of your document windows. Customizing the window (as Dave did with his spinning arrows) is up to you. Sprocket handles generic window behavior like clicks in a window’s close, grow, or zoom area. When drawing is necessary, Sprocket will call the window’s Draw() method, which you’ll override with your own Draw routine. You’ll see how to do that in next month’s column.

Figure 3. A generic Sprocket document window with the spinning cursors.

If you select Preferences... from the File menu, the preferences dialog in Figure 4 will appear. This will eventually evolve into a scrolling list of icons, each of which gives the user access to a different portion of the application preferences. Got any ideas for this dialog? Send ‘em in!

The Sprocket menu bar is pretty generic (appropriately so). It features standard File and Edit menus, as well as a not-so-standard Debug menu. If your Mac is AOCE aware (if you have PowerTalk installed, for example), the Debug menu will feature an an item that lets you create a new window with an AOCE mailer attached to it.

If you want to explore this topic further (we won’t get into it for a while) search for the flag qAOCEAware. If you won’t be supporting AOCE, you’ll want to turn this flag off, since it will save you considerably in code size.

Figure 4. The Sprocket generic preferences dialog as it appeared in November.

Let’s take a look at two of the files in the Application Specific group. The first of these files, AppSpecific.rsrc, holds the resources you want to add to Sprocket. The second file, App.cp, holds the nine routines that you’ll need to provide to customize Sprocket. We’ll get to the rest of the Application Specific files in next month’s column.

AppSpecific.rsrc

Sprocket divides its resources between two resource files. Sprocket.rsrc contains the resources that are private to Sprocket, while AppSpecific.rsrc contains the resources you’ll add to the project yourself. Take some time to look through the resources that come with the generic Sprocket project. As you look through AppSpecific.rsrc, you’ll notice that there are MENU resources for the Apple and Debug menus, but that there are no MENUs for the File and Edit menus. The File and Edit menus are defined in Sprocket.rsrc. Notice that the Debug menu is not included in the MBAR resource used by Sprocket (MBAR 128). The Debug menu was added by Sprocket using a call to InsertMenu() (Look in App.cp for the constant mDebug to follow this process). Take all this with a grain of salt, since it will most likely change in the near future. By the time you read this, a new version of Sprocket that gives you complete control over the menu bar will be released. The plan is that you will provide an MBAR resource and MENU resources to go along with the MENU ids listed in the MBAR resource. At this point, it’s not clear how the File and Edit menus will be handled. More on this as Sprocket evolves.

App.cp

This is the most important of your source code files. Here’s where the aforementioned 9 mandatory routines reside. As you get started, you’ll want to edit a copy of App.cp, using the existing 9 routines as the basis for your own code. Here’s the function prototypes for these 9 routines which you must supply (the prototypes are at the very bottom of <Sprocket.h>):

// initialization & tear down
extern  OSErr  SetupApplication(void);
extern  voidTearDownApplication(void);

// menu handling:
extern  voidHandleMenu(TWindow * topWindowObj,long menuCode);

// scrap coercion hooks:
extern  voidWriteLocalClipboardToScrap(void);
extern  voidReadLocalClipboardFromScrap(void);

// document handling routines:
extern  OSErr  CreateNewDocument(void);
extern  OSErr  OpenDocument(LetterDescriptor *,void *);
extern  OSErr  PrintDocument(LetterDescriptor *,void *);
extern  Boolean  QuitApplication(void);

SetupApplication() is where you’ll do your application specific initialization. You’ll have to learn what Sprocket does and doesn’t do for you. For example, Sprocket doesn’t set up QuickTime and it only installs handlers for the four required Apple events.

In TearDownApplication(), your documents have already been closed and you know that your application is going down. Here’s a chance to write out your preferences file, shut down any network connections, etc.

HandleMenu() is your menu selection dispatch routine. The first parameter is a pointer to an object that represents the active window at the time the selection was made. The second parameter is a standard four byte menu/item combination you can take apart with HiWord() and LoWord(). You can dispatch menu selections using C or C++, whichever works for you. That’s one of the nice things about Sprocket. Though it is definitely C++ based, it doesn’t force you to work in C++. The generic Sprocket application does all its menu item processing inside the HandleMenu() routine, but you’ll probably want to shift the processing into a separate file.

The routines ReadLocalClipboardFromScrap() and WriteLocalClipboardToScrap() load the scrap into the local clipboard and write the local clipboard back out to the scrap. You’ll fill these routines in when you’re ready to support the Cut, Copy, and Paste Edit menu items.

CreateNewDocument() gets called by the oapp Apple event handler. No matter what horrid error you encounter, do not exit the program inside this routine or you will completely hose the Apple Event Manager. Use this routine to create a new document object. If you encounter an error, return the error code, otherwise return noErr.

OpenDocument() gets called by the odoc Apple Event handler for each document used to launch the application. A recordable application will also create and send an odoc event to itself when the user selects Open... from the File menu. At this point, Sprocket is not recordable (sounds like an idea for a future column). OpenDocument() should use the information in the LetterDescriptor parameter to open a file and use the information in the file to create a new document object. A LetterDescriptor is a union, holding either an FSSpec or an AOCE letter spec. The union starts with a boolean that indicates which type it is. Again, be sure you don’t exit directly from this routine. If you encounter an error, return the error code, otherwise return noErr.

PrintDocument() will get called in response to a pdoc Apple event. Sprocket doesn’t have printing support yet, so leave this routine until printing is there.

QuitApplication() gets called in response to a quit Apple event. QuitApplication() should close every open document. You might want to maintain a list of open document objects, then have QuitApplication() step through the list, calling each document’s Close() member function (also known as the document’s Close() method). If a document has been changed since it was opened, the Close() method should put up the standard “Save changes” alert, giving the user the chance to cancel the quit. If the user cancels the quit, QuitApplication() should return false. If all the documents close successfully, QuitApplication() should return true, and Sprocket will call TearDownApplication().

Till Next Month

In next month’s column, we’ll take a look at the files that define the window objects used by Sprocket. We’ll customize Sprocket by overriding some of the different window Draw() methods. Between now and then, take some time to read through the files App.cp, DocWindow.cp, ToolWindow.cp, PreferencesDialogWIndow.cp, and MailableDocWindow.cp. Experiment. Open up the “.h” file associated with each of these files and check out the class definition that forms the basis for each file. You’ll see that each of these window classes is derived from Sprocket’s TWindow class. Check out the DocWindow class. Notice that it overrides the TWindow Draw() method. If you want to affect what gets drawn in a DocWindow, you’ll want to edit the DocWindow Draw() method. Try it! Just be sure to make a copy of the Sprocket project file and AppSpecific folder so you’ll maintain your original copy of Sprocket (just in case).