AppMaker 1.5.1 & Marksman 2.0

How do these two tools for interface design stack up?

By Kirk Chase, Former MacTutor Editor

Introduction

They say that in life there are only two things you can be sure of - Death and Taxes. With software development, we can add Not Enough Memory, Not Enough Speed, and Not Enough Time. Time is often the critical factor. Not enough time to plan the project carefully, not enough time to tweak the code, and not enough time to test it properly.

A number of tools are available to aid software developers (just look through the ads of MacTutor). Two tools available to aid in interface design are AppMaker by Bowers Development and Marksman (formerly known as Prototyper) by ITMakers. These two products are quite similar. Both aid you in designing interface elements such as menus, windows, and buttons. And both will generate a source code skeleton as well as the necessary resource files to handle the interface you created.

In this review, I shall look at five different areas in both products: Installation & Documentation, Design Features, Extra Goodies, Code Generation, and Code Quality. Hopefully this review will aid you in deciding which tool is best for you.

Installation & Documentation

Although not of primary importance, I would like to briefly look at installation and documentation. Both AppMaker and Marksman come to you on two disks with self-extracting archives on them. A minor nuisance of AppMaker is that all files for every operating environment are extracted. Marksman does put the important stuff on one disk. A real installer would be an improvement in both products.

AppMaker’s documentation has really grown up over the revisions. It is very clean and professionally done. It is well organized with a much better job at discussing what to expect after you have generated your source code. Hats off to the documentation and package design team. I have only one suggestion for their next documentation revision. I would like a more formal discussion on code generation/modification. All the discussion on code is done in the “example” section and none in the “manual” section; although an example greatly aids in explanations, I feel a more formal and complete discussion would be an improvement, perhaps something like Inside Macintosh.

AppMaker comes with basically two examples to help get you off the ground. The first example is to allow developers to quickly familiarize themselves with the way interfaces are created. The second example is targeted to the code that is generated, the layout and ways to modify it. You will definitely need AppMaker and/or the code examples up on your Macintosh to fully understand the examples in the manual.

Marksman’s documentation does a fairly good job as well. It does lack in few areas, such as installation instructions, and the design tools’ description section seems like a copy/paste job from one tool description to another. Also, a few things are left out of the instructions entirely. Most of these omissions are in the discussion of design tools-which is fairly intuitive. Marksman does a good job on discussing the code that is generated and has an excellent example on creating AppleEvents. The manual, though, could be improved greatly.

Marksman comes with a “do all” example showing most of the tools and how they interact. I would have preferred a step-by-step example, but this does offer a chance to look at how it handles most things. Marksman does come with “Demo Windows” code which may be viewed as an example too.

Interface Design

Interface design is one of the two major functions of both products. They allow you to design menus, windows, and so on.

Menus

AppMaker organizes the menus into menu bars. You have the main menu bar that will be loaded at start up. You also can have a menu bar for any hierarchical menus, pop-up menus, and so on. Menus are created in a “screen-like” environment. Dividing lines and command-key equivalents may be added. If you are designing for an OOP environment, menu command numbers may be entered as well. Menus and menu items can easily be moved around. Menu ids may also be edited.

Beyond normal menus, you may have other menu types. Hierarchical menus can be created beforehand or at the time the parent menu is created. You may also have picture menus (i.e., tools or patterns). You must have created the picture to use this type, but these picture menus can be displayed as text to assign names and command keys. Font menus are created for you automatically if you have a menu called “Font”.

Marksman has only one menu bar. It does not have picture menus, and it only supports one level of hierarchical menus, but it does support icons (and icon editing), initial dimming, and check marks. These may seem small concerns, but it does decrease the amount of editing in ResEdit or code initialization. There is no auto-“Font” menu or picture menu for Marksman like AppMaker’s.

Windows

AppMaker offers all eight standard window types for windows, dialogs and alerts along with the option for a Close box. You may designate the window’s ID, name and title. In addition, you can designate its ProcID and whether you want it opened at start up. You also have available System 7’s movable modal dialog window and any custom WDEF (this must be created beforehand); this is useful for floating windows which are supported by OOP systems.

Windows can be positioned and resized. All their attributes can be edited. Be aware that AppMaker treats the Movable, DBox, PlainDBox, and AltDBox as modal windows. You can create windows as windows, dialog boxes, or alert boxes, but you cannot edit the stages of an alert.

Marksman also has the standard windows and System 7’s movable modal dialog. You can also edit their attributes such as title, displayed at start-up, and a Close box. One thing you will find is that the window’s title is also its variable/file name; this is in contrast to AppMaker which lets you assign a separate name as well as a window title (for example, text windows may be titled “untitled”). Naming variables is a great help in working with the code later on. You will find out later that the Marksman generally lets you name variables, and AppMaker doesn’t.

In addition to this, you will find two windows in Marksman intended for floating windows (one with the drag bar across the top and one down the left side). That’s right, all standard windows may be floating windows. This is definitely a nice feature in Marksman. Code is generated to handle the floating windows. [Although AppMaker doesn’t handle floating windows in all environments, you can have floating windows when using TCL. - Ed.] In alerts, you can edit the stages. You may also use the Plugin application to install up to six custom windows.

One big difference between the products is that in AppMaker all windows are set up so that multiple instances of any particular window may exist. Marksman windows are geared to be single instance windows. Now this does not mean that Marksman cannot handle multiple instances of a window type, it has regular hooks for just such a case. With those windows, you are on your own with creating and handling them. [Consequently, the handling of multiple documents in AppMaker is easier than in Marksman. - Ed.]

Design Aids

AppMaker gives you little in the way of design aids. You may turn on and off an invisible grid which is always 4 pixels (this is good since most text sizes and resources such as icons are multiples of 4). You may align items in various ways, and you may show text baselines, item numbers, and command numbers. There is another option of showing screen sizes of a 9-inch and 13-inch monitor; this is only helpful in designing for small screens on larger ones. There is also an Item Info window to allow you to manually enter in position, size, whether it responds to mouse clicks, and OOP information (I wish this window were a floating window).

Marksman gives you design aid after design aid. It is rich in design aids when compared with AppMaker. Marksman has a user-definable grid to snap things to. Also there are separate guidelines for alignment. Coordinates are constantly shown. You may also move items a pixel at a time by the arrow keys. If you hold down the command key, the arrow keys adjust the item’s enclosing rectangle a pixel at a time. This is a big plus in my book. [AppMaker also allows for movement by arrow keys. The arrow keys move an item a grid unit at a time or a pixel at a time depending on if the grid is on or off. - Ed.]

Windows may be placed graphically. They can be auto-centered both vertically and horizontally. You can do this on either a simulated 9-inch, 13-inch, and 12-inch screen. One feature that I like is the ability to see a window’s position in relation to another’s position. I just wish it went a little further by letting you position windows relative to other windows.

There are two big features in Marksman that make it really standout in the area of design. The first one is “linking”. Almost every action, such as selecting a menu, pressing a button, or opening a window can be linked to certain actions. Such actions include enabling/disabling a menu or menu item, checking/unchecking/toggling a menu item, opening/closing windows, enabling/disabling controls, setting controls, and showing/hiding controls. A lot of the tedious coding can be taken care of automatically for you. About the only thing it doesn’t link is a scroll bar to a text edit field. You may also print out a report of these links.

Marksman has the ability to simulate your design with all its links. This allows you to “play” with your design, see the dialog come up from a menu selection, play with radio buttons, bring up windows, or any other link. This simulator is a big plus. Generating code with either product can be time consuming. The Marksman simulator allows you to get a feel of it before you have to generate and compile the code.

Basic Window Items

There are some basic window items such as buttons and scroll bars. Probably the best way to go about describing both products’ basic window items is in a list. These items are normally selected without too much extra work on the developer. “AM” is AppMaker, and “MM” is Marksman.

With AppMaker, all items may be moved or resized. Their item numbers may be reassigned by cutting and pasting (this is a terrible way to do this, but item numbers are not always critical in designing an interface). In OOP, there are a few more tools [this includes changing fonts, size, etc for buttons, check boxes, radios, popups, etc when used with TCL or MacApp -Ed.], but these are the basics. Marksman allows you to move or resize items as well. They are not given item numbers as AppMaker, but you can send things to the back or front as in many drawing applications.

Color

AppMaker makes little use of color. Color is basically supported (color windows are opened if available), but they are not editable in AppMaker. Marksman supports color and allows you to edit the various colors.

System 7

Current versions of each products were introduced to support System 7. AppMaker will generate AppleEvent code to handle the four required events. Their AEvent.c is not finished since it requires application specific code. AppMaker lets you design Balloon Help for menus and window items, and further, it understands the limitations of the environment you are generating code for. For example, if you are developing for MacApp windows, you will have all four balloon states available, but if you are developing help for TCL windows, you will be limited to one balloon state because that is all that TCL supports. Text only balloons are supported in the editor.

Marksman supports both the four required AppleEvents and AppleEvent suites. This is done through a separate editor and code library. In the AppleEvents editor, you can create your own suite of AppleEvents. There are a number of standard classes already defined. It is not the most user-friendly editor, but it does the job.

Extras

AppMaker is filled with a number of “goodies”. Perhaps the best of all of them is the way the source code is generated. This is done by “template” resources that you can edit and modify. You can change them if they don’t suit your taste (like “/* Be sure to lock handle */” after a toolbox routine that moves memory, or your name automatically added to the source code). This is very useful in adapting the source code generated to your style.

Another extra is all the code aids. There are many generic routines already written to help you. There are routines for handling lists and controls. There are a number of routines for dialogs and basic scrap management, cursors, sound, and file operations. There is also code for helping with scroll bars, text fields, and generic linked lists. AppMaker also provides the source for its CDEFs and MDEF.

Marksman provides a lot of extras. It provides numerous extra controls by the use of “Plugins”. There are plugins for color buttons, pictures, small icons, icons, and rectangles, buttons that involve text and sound, and alternative scroll bars. The basic tool comparison chart I made could have been a lot bigger by installing all the CDEFs that came with Marksman.

Marksman also helps in code examples. I mentioned before that the Demo Windows source code was given. Code for all their plugins and window definitions are given too. Not too much is given in the way of generic source code routines as with AppMaker. If it isn’t implemented in the prototype, then it doesn’t get put into the code. Marksman does implement user events which aids in performing AppleEvents-like processing. Still, it would be nice if Marksman generated generic window/menu aids. Often times you don’t want to go through the hassles of creating another “event” to change something you already have access to. Not being able to edit the code created is a big minus in my book.

Code Generation

The second major function of both products is code generation. This includes what languages it supports, how the code is laid out, code quality, how easy is it to modify, and regeneration of interface design. Rather than using the examples that come with each product, I decided to take a semi “real-world” example. Since “all in one” applications are the fashion these days, I decided to make my own and call it “TheWorks”. I will go over the design of TheWorks with both AppMaker and Marksman.

TheWorks would have a word processor module called “Shakespeare”. There would also be a paint module called “Leonardo”. Since multimedia and QuickTime are also the rage, I wanted to put in my own called “GoofTime”; this would consist of an area where two icon robots would constantly move around randomly whether or not their window was in the background. I knew there should also be a communication module, but token ring protocols are too simple. So I decided to have a Parent/Teenager communication module (something very difficult).

Preparation

You better be prepared to use a drawing program and ResEdit with these two products. You should design your icons, pictures, etc. and paste them in during editing. These products do not claim to be drawing programs. Marksman does let you create bitmap-typed resources such as icons. For Marksman, I needed to add a picture button control. This was easy to get using the Plugin Installer.

Languages

It is here that AppMaker shines. Since AppMaker is a template driven code generator, you can generate code for THINK C, THINK C with TCL, THINK Pascal, THINK Pascal with TCL, THINK Pascal with MacApp 2.0, MPW C, MPW C++ with MacApp 2.0, MPW C++ with MacApp 3.0, MPW Pascal, MPW Pascal with MacApp 2.0, A/UX ANSI C, and Modula-2 with MacApp 2.0. FORTRAN and XVT are available separately. Just be sure to decide on what language before you start since switching mid-stream is not always possible.

Marksman only handles the major languages. It generates code for MPW C and Pascal, THINK C and Pascal, and THINK C and Pascal using TCL. A major language absent from this is support for MacApp for either THINK or MPW. Unfortunately, Marksman code generators can not be modified like you can with AppMaker. Although this may seem like a little used feature, it does help in getting that code generated the way you like it.

Interface Design

The following summarizes what I designed in TheWorks. TheWorks has 6 menus: Apple, File, Edit, Text, Patterns, and Windows menus. I did not touch the Apple, File, and Edit menus except to change the About menu title; AppMaker already had Publish and Subscribe items in the Edit menu. The Text menu has three hierarchical menus: Font (this is created during application time), Size (having various sizes), and Class (having the “class” of the text document). The Pattern menu was a picture menu of some patterns to be used in the paint module. The Windows menu contained an entry for each module to bring up its window quickly.

Unfortunately, there is no picture menu in Marksman. I was not able to implement the Pattern menu. Marksman does have floating windows. So I implemented the pattern menu as a floating window. This seemed an acceptable solution to my project. However, other projects might work better with a picture menu. These are two differences you will need to weigh. Wouldn’t it be nice if they had tear-off menu support?

In Shakespeare I created a regular, sizable document window. I created a horizontal and vertical scroll bar along with my editable text field. Both products took care of making sure my scroll bars were at the window’s edge. Leonardo was even simpler. I created a paint tools palette and a user item area for the canvas.

GoofTime was a little more elaborate. I had a field where the robots would be going around until they crashed into each other. There were two picture sliders to control the speed of each robot, a “Start” button, a “Restart” button, and two icons showing each robot. The moving robots would just be simple icons and the resulting crash would also be an icon.

The Parent/Teenager communication window had a text field and scroll bar to display incoming text, and edit text field and scroll bar to type outgoing text. There is also a “Speak” picture button and a picture of a speaker. Since this was a Macintosh application, I simply duplicated the Parent window and changed the name for the Teenager window.

Code Layout For AppMaker

Upon generating code, you will have a number of files. I choose THINK C for my language. The files created are in the table shown (names in italics are files that depend on the window, menu, or application name).

The rest of the files are loaded in by means of a library. The library source is supplied if you need to change it. I like this approach since it keeps you from having to deal with the standard code that is in nearly every application. It does have the disadvantage of not being available for debugging purposes. [On the other hand, if you want the code for debugging, you can use the source instead of the library. - Ed.] AppMaker gives a very clean layout in its code generation. Once you understand the way files are generated, you will know which files to re-generate when interface changes are made.

The most important structure in AppMaker is the window information record. It contains general fields such as window kind and file information. It also contains handles and variables to window items. It is here that you would place other items needed for handling your windows like flags and variables. There are five important global variables associated with windows: curWindow - points to the current window, cur - points to current window information record, curEvent -holds latest event, sysConfig - holds current system features, and inBackground - flag indicating if application is in background.

This method of storing window variables is nice, but it has its drawbacks. First, all window type variables are held in a single record structure. Not only does this add extra variables to each window, labels must be unique between windows (something you can’t edit). This brings up the second drawback, the labels for controls and ID constants are okay in some instances, but in other instances they use the item number and type for name creation. This allows for silly looking names as well as possible naming conflicts. I ran into this when duplicating the Teenager window from the Parent window. It would be nice if AppMaker allowed you to pick the variable name for interface items, as well as adding variables not connected with interface items to the info record of windows and dialogs during interface editing.

What I would rather see in the window info record is a standard header with either a handle to user data or a piggyback technique. A piggyback technique can be seen readily in the grafport/window/dialog structures where each adds to the former. This allows you to use the same pointer for the former structures while your private data structures tag along.

The third drawback has to do with code re-generation due to an interface change. Since the window information record holds interface variables as well as your own window variables, you must re-generate the Global files nearly every time. Then you must re-add your own window variables. On top of this, you must practically re-compile every file since nearly every one uses Global.h. But once you have got the window information structure stable, you will find AppMaker’s code layout nearly intuitive and easy to change.

File Description

ResourceDefs.c & h ID constants for most resource types and menu items

Globals.c & h Handles initialization of global data, system configuration and window info records. Dialogs have their own private structures, and alerts are just called from library functions

applicationMain.c main entry point, initializing variables and toolbox structures, and handling Finder launches

applicationData.c & h Stub file for working with file I/O

Dispatcher.c & h Handles routing events to proper window

window.c & h Handles window specific events. Item ID constants are in the .c file. Dialogs have their record structures in the .h file

MainMenu.c & h Loads and updates menus. It also routes menu events to specific menu files

menu.c & h Handles menu specific initialization and events

Code Layout For Marksman

Upon generating code, you will have a number of files. Again, I choose THINK C for my language. The files created are in the table below (names in italics are files that depend on the window, menu, or application name).

This may seem at first to be a lot of files when compared to AppMaker, but you must keep in mind that AppMaker’s bulk is kept in a library. Marksman generates all the code every time you create a new project. The files in the upper half of the table are the “private” files, and the second half is the “user” files. Don’t ask me why the naming scheme is not consistent. It’s that way within the files as well.

The idea around this file scheme is that all the files get generated the first time around. The files in the upper half implement the general Macintosh code and the user interface you created in Marksman. The files in the lower half are hooks into the upper files, and there are a lot of hooks. In this manner, the code you write (in the user files) is not touched when you update your interface. This is unlike AppMaker where you lose your added code when the interface gets updated.

The code layout of Marksman is somewhat confusing at first. In general, Main_application initializes menus and windows by first calling their private initialization routines and then their user initialization routines. When an event is for a particular window, the private routine is called first, and then the user hook routine is called. Menus are handled the same way except the user routines are called twice, once before the private routine does anything and then after the private routine. This allows you to completely override the normal menu handling. User defined windows are farmed out to Eventsapplication.c, and user defined menus are sent on to Menu_application for processing.

Once realizing the way the code jumps from one file to another, you will find some other items of interest. As I said before, with Marksman, you can name nearly all of your variables. There is no window information record as in AppMaker since multiple instances of a window must be user created. All the variables for every window are contained in PComUtil_application. There is no information hiding. Everything is global! Marksman takes AppMaker’s window info record problem to a new level.

Code Quality

It is very difficult to tell you whether I like one code style over the other since they both handle generated code differently. Perhaps a little history on what I had to do to get them both functionally “equivalent” after I generated the code.

With AppMaker, I needed to add in menu updating code. This was not too difficult since there are a couple useful menu routines and the curWindow global. I also had to add code for initialization of check marks. To implement the Window menu, I either had to walk the window list or keep a global pointer to each window. For Marksman, I needed to add code for creating and handling the Font menu; user events created with the editor took care of most of the menu updating.

There was not much to do with making the windows functionally similar. Unfortunately, I did not have the ability to create multiple instances of a window with Marksman that I did with AppMaker. On the other hand, there is no event loop hook with AppMaker to run my robots in GoofTime like I had with Marksman, and the Parent/Teenager Communication windows needed a few globals with AppMaker to implement message passing. Fortunately with AppMaker, you have the library code and the code templates to take care of any problems.

With Marksman, there were times that I wanted to update menus differently. Sending a user event to open or close a window may be fine, but menu items can be updated so rapidly. Take this example. You have certain menus and menu items that become active when certain windows are in the front. So you link in menu items with each window type. Now let’s suppose that you close a window (A) which brings up a window (B) that is linked to close. Window A closes and sends events to update the menu bar (one item at a time) and close Window B. Window B becomes active and sends out its events to change the menu bar. The user event comes in to close Window B. Now Window C finally comes up and sends out events to update the menu bar for a third time.

Now I love the idea of user events. In my mind, there should be a little more intelligence. Sending out an event for every menu item change is wasteful. It would be nicer if you could say in an event, turn off menu items 1-12 and switch on menu item 8. Or a conditional event that says suppress events from Window B because it’s not going to be around in a little while. Now all this I suppose could be written in, but that is coding you really didn’t want to do in the first place.

Code Regeneration

Nobody’s interface design is going to be perfect the first time. You will probably have to re-generate your code after another session with the editor of each product. For Marksman, you basically re-generate the private files plus any new user files. The code you added is safe since it should be in the user files. With AppMaker, you will need an understanding of which files to regenerate. This may be as simple as a couple of files all the way to nearly every file. And with AppMaker, say, “Hasta la vista, bebe” to any code you put in the old files. At best you can cut and pastes those sections back in. There is a ray of sunlight coming through. AppMaker’s source code can be altered by you to add “Marksman”-like hooks. I told you that the ability to alter code generation is a big plus.

File Description

Main_application.c Entry point and main event loop

PComUtil_application.c &h Handles global data, variables for windows, resource IDs, common utility functions, and user events

PD_dialog.c & h Handles dialogs

PW_window.c & h Handles window events

PMenu_application.c & h Handles menus

InitExitapplication.c & h User hooks for initialization and exiting

Eventsapplication.c & h User hooks into main event loop. Generally this is for handling user created windows and menus

ComUtil_application.c & h User hooks into common utilities. Generally this is for handling user defined events

dialog.c & h Handles user hooks into dialogs

window.c & h Handles user hooks into windows

Menu_application.c & h Handles user hooks into menus

Conclusion

Who is better? It is hard to say. I like AppMaker’s code style and love the ability to alter it. There aren’t as many hooks with AppMaker as you have with Marksman. I would still give AppMaker’s code output better marks in many respects to Marksman’s code output. Many things are done intelligently, but loss of code at regeneration and the lack of being able to label fields and variables mars this advantage of AppMaker.

Marksman’s editor, I feel, has AppMaker’s editor beat, hands down. This is not to say that I am totally pleased with Marksman’s editor. I like many parts of AppMaker’s better, especially the menu and text field editors. Still Marksman’s editor, especially combined with the simulator, beats AppMaker.

Both products have many strengths and weaknesses. As developers, you will have to decide which tool is best for your needs. Some will prefer Marksman for its editor, simulation and linking ability. Others will prefer AppMaker for its code output. I’ve wished many times to be able to use Marksman’s editor, and then generate code in AppMaker. Both are good products and do a great deal in helping get the product out the door in time.

Item AM MM Notes

Buttons X X MM: buttons in dialogs may be designated as the default button and have bold outlines drawn around them and whether they dismiss the dialog/alert.

Check Boxes X X

Radio Buttons X X AM: radio button groups are designated by consecutive radio buttons; this first one is “on” by default

MM: you may assign up to 10 radio groups (certainly enough for a single window).

Static Text X X AM: lets you change the font and style options for the whole text block. Text may be directly edited. A font may be designated as “system” or “application”.

MM: also lets you change font and style as well as the option to limit text to a single line.

Edit Text X X AM: like that of static text. Numeric only fields can be defined

MM: like that of static text. No numeric only fields.

Icons X X AM: Icons can be graphics or buttons. If they are buttons, the original is highlighted by inverting it

MM: Icons may be also be graphic or buttons. They may also be dimmed.

Pictures X X AM: Picture buttons are handled elsewhere

MM: Pictures may be buttons, but they are not highlighted. They may be clipped/resized to the tool’s rectangle or the tool’s rectangle may be altered to fit the picture.

Lines X X AM: Draws only dotted lines. To have solid lines you must use a rectangle. The dotted lines must be horizontal, vertical or a down-right diagonal

MM: Dashed or various pixel widths. Horizontal or vertical lines only.

Rectangles X X AM: Draws only single pixel rectangles.

MM: A rectangle may or may not have a frame of various widths and a drop shadow or various width. It can display a label and it may be considered a hot spot (used for user items).

Pop-up menus X X AM: System 7 looking pop-up. Can create one without a label.

MM: same as AM, but menu items can also be dimmed or initially selected.

Scroll bars X X AM: Creates it in standard width. It extends scroll bars if at the window’s edge to the window’s size box. Scrolling panes may be optionally created for OOP environments

MM: Like AM, you may in addition select the Max., Min., and Current scroll values as well as the line and page increments.

Labeled

Rectangles X X AM: Used for grouping radio buttons.

MM: see Rectangles

Palettes X X AM: First item is selected by default. Hilighting options available.

MM: Like AM, and you may select any tool to be the default tool.

Lists X X MM: Lets you set up items in list

Picture Buttons X X AM: These buttons may be regular, radio, or check boxes. An on and off picture may be designated

MM: This is handled as a Plugin.

Multi-state

Buttons X AM: These are picture buttons with a picture designated to all of its states.

Picture Slider X AM: This is a scroll bar that uses a picture for the scroll area and the thumb

Custom Controls X X AM: A CNTL resource that has been previously created may be used to add even more custom controls. Why AM doesn’t let you create CNTL resources on the fly is a mystery to me.

MM: Custom controls are handled by “Plugins”. Many of which are similar to the few standard buttons offered by AM.

User

Item/Hot Spot X X AM: Defines an area in a window that can receive mouse clicks. Used for dialog/alert user item

MM: See Rectangles

For more information, contact:

Bowers Development

AppMaker, Retail Price: US $299

P.O. Box 9, Lincoln Center, MA 01773

Phone: 508/369-8175, Fax: 508/369-8224, AppleLink: D1721

IT Makers

Marksman, Retail Price: US $149

P.O. Box 730152, San Jose, CA 95173

Phone: 408/274-8669, AppleLink: ITMAKERS