Path: utzoo!utgpu!news-server.csri.toronto.edu!mailrus!uunet!samsung!zaphod.mps.ohio-state.edu!mips!apple!Apple.COM!lsr
From: lsr@Apple.COM (Larry Rosenstein)
Newsgroups: comp.sys.mac.programmer
Subject: Re: MacApp: Extending the zoom box User Interface
Message-ID: <8013@goofy.Apple.COM>
Date: 2 May 90 17:10:51 GMT
References: <24079@mimsy.umd.edu>
Sender: usenet@Apple.COM
Distribution: usa
Organization: Objects-R-Us,  Apple Computer, Inc.
Lines: 48

In article <24079@mimsy.umd.edu> sla@brillig.umd.edu (Steve Armentrout) 
writes:

> User Interface of the zoom box.  This window has five user-states that
> are simply different sized windows/views on the same data.  I would like

> favorite idea is to use the two regions of the standard zoom box to
> differentiate between zoom-in and zoom-out.  For example:

I don't think this is a good user interface extension.  To the user the 
windows look the same, yet the zoom box is slightly different. Plus, I 
think dividing the zoom box will result in very small hit areas.  (It's 
not just senior citizens who will have trouble with small hit regions.)

MacDraw II has menu commands to manage views of the document (scale 
factor, scroll position, etc.), and I don't see that there's anything 
wrong with having a menu of the possible user states, and even a mechanism 
for the user to select the different states.  Then the zoom box can be 
used to toggle between the selected state and the full-screen state.

Then you can use command keys for shortcuts.  If you wanted to use buttons 
for the short cut, then I would suggest that you place them within the 
window.  Again, MacDraw II does a good job with placing the scaling 
buttons in the window.  Powerpoint also does a similar thing to switch 
between the actual slides, the slide sorter, and the slide titles.

> The best try I have at the moment is to override ZoomByUser to create 
> and post a ZoomBoxTracker command which will provide the aforementioned 

You can draw in the title bar of the window using the normal mechanisms.  
When you draw in a window, drawing is clipped to the content area.  You 
should probably do what the system does and draw in the Window Manager 
port  It's not going to matter what you use for the fView in your tracker. 
 In fact, using MacApp's tracker's in this case won't be very useful, and 
will be more overhead than you need.

If you place buttons in the content area of the window, then you can make 
them normal MacApp views (instances of TPicture, perhaps) and then MacApp 
will take care of tracking them for you.  You will only need to override 
the DoChoice method, which will get called when the user clicks one of the 
buttons.


Larry Rosenstein, Apple Computer, Inc.
Object Specialist

Internet: lsr@Apple.com   UUCP: {nsc, sun}!apple!lsr
AppleLink: Rosenstein1