keith@Apple.COM (Keith Rollin) (05/02/90)
In article <24079@mimsy.umd.edu> sla@brillig.umd.edu (Steve Armentrout) writes: > >I have a window in my application for which I would like to extend the >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 >to allow the user to "zoom" in and out through these user-states without >having to expend the real estate required for a grow box. Currently, my >favorite idea is to use the two regions of the standard zoom box to >differentiate between zoom-in and zoom-out. For example: > > xxxxxxxxx > x x x > x IN x x > xxxxxx x > x OUT x > xxxxxxxxx > >If the user clicks on the zoom box, the region receiving the click >(IN or OUT) would hilite. If the user drags from one region to the >other, the hiliting will toggle to the newly occupied region. If >the mouseUp occurs in region IN then the window will zoom-in (ie get >smaller) and similarly, a mouseUp in region OUT will zoom-out. > >User Interface question: Is this a plausible extention to the User >Interface of the zoom box? The only objection I can forsee is that the >regions may be a bit small (note: my application is not targeting the >senior citizen market). > >Technical question: How do I implement this behavior most simply using >MacApp? > >The best try I have at the moment is to override ZoomByUser to create >and post a ZoomBoxTracker command which will provide the aforementioned >hiliting and call Zoom as appropriate. Can I simply set the fView of >the ZoomBoxTracker to be my window to allow drawing in the title bar >(more specifically the zoom box) of the window? I realize that the drawing >performed by my ZoomBoxTracker would not be under the auspice of MacApp, >so what do I need to do in order to draw? > >The other technique I have in mind is to stuff the global var DragHook >with my own procedure, but the documentation is unclear as to whether >this will work. IM I roughly states that "the highlighting will depend >upon the window function defined for the window". If I use DragHook, will >my procedure be called by TrackBox INSTEAD of the window function or in >ADDITION to the window function? > >Some insightful comments could save me some time. Steve, Probably the best way to do the tracking would be to take the standard WDEF and modify it so that it does the right kind of tracking on the zoom box (you can get the source to the WDEF from our ftp site). You can't really have MacApp do the tracking, as MacApp (as in all other applications) only tracks the mouse in the content region of the window, not the frame. If you do change the standard action of the zoom box, then you may also wish to changes its appearance. Either make the box a different shape, or replace it with two other boxes that can't get confused with the standard zoom box. -- ------------------------------------------------------------------------------ Keith Rollin --- Apple Computer, Inc. --- Developer Technical Support INTERNET: keith@apple.com UUCP: {decwrl, hoptoad, nsc, sun, amdahl}!apple!keith "Argue for your Apple, and sure enough, it's yours" - Keith Rollin, Contusions
lsr@Apple.COM (Larry Rosenstein) (05/03/90)
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
murat@farcomp.UUCP (Murat Konar) (05/04/90)
In article <24079@mimsy.umd.edu> sla@brillig.umd.edu (Steve Armentrout) writes: > >I have a window in my application for which I would like to extend the >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 >to allow the user to "zoom" in and out through these user-states without >having to expend the real estate required for a grow box. Currently, my >favorite idea is to use the two regions of the standard zoom box to >differentiate between zoom-in and zoom-out. For example: [the rest deleted in the interest of berevity] I think this is a truly bizarre perversion of the user interface. Might I humbly suggest three alternatives: 1) Use menus (with command key equivs, of course). 2) Write a new WDEF with more zoom boxes. 3) Use the modifier keys to signal the desired state when clicking in the zoom box. 4) Have some kind of buttons or icons in the area normally occupied by scrollbars. Easiest is option 1. Coolest is option 2. It is also the hardest. Incidentally, TrackBox will not call DragHook AT ALL. It calls the WDEF of the window with wHit and wDraw messages. The WDEF does all the drawing. Only if the WDEF calls DragGrayRgn (directly or indirectly) will DragHook get called. This would be a really weird thing for a WDEF to do and the standard Apple WDEF certainly does not do this. -- ____________________________________________________________________ Have a day. :^| Murat N. Konar murat@farcomp.UUCP -or- farcomp!murat@apple.com