[comp.sys.mac.programmer] Question: scrolling in a window

reiss@husc9.harvard.edu (Peter Reiss) (03/15/91)

I have implemented scroll bars in a program and they work, except that whenever
the user clicks in the arrow region, I am redrawing the entire picture.  This
works, but does not look very good.  I have noticed that most programs seem to 
scroll graphics by shifting the current picture in one direction and drawing
in the extra area.  How can I do this?

2fmlcalls@kuhub.cc.ukans.edu (03/16/91)

In article <1991Mar15.032155.305@husc3.harvard.edu>, reiss@husc9.harvard.edu (Peter Reiss) writes:
> I have implemented scroll bars in a program and they work, except that whenever
> the user clicks in the arrow region, I am redrawing the entire picture.  This
> works, but does not look very good.  I have noticed that most programs seem to 
> scroll graphics by shifting the current picture in one direction and drawing
> in the extra area.  How can I do this?

Try :

procedure ScrollRect (theRect:Rect; hScroll:Integer; vScroll:Integer;
updateRgn:RgnHandle);

theRect would be a rect in local coords of your window (be sure to SetPort() to
your window before calling this).  If the scroll bar is vertical, just pass 0
in for hScroll (or vise-versa if vice-versa).  Be sure you have predefines
updateRgn with xxx:=NewRgn.  Once scrolled, the procedure will fill in your
updateRgn with the rgn corresponding to the new 'white' (background) area
exposed by the scroll.  It is your job to fill in the newly exposed hole.  You
could use the rgn returned as a clipping region to your window port for a
DrawPicture or CopyBits.  That way the whole window isn't redrawn.  Just set
your clip back after the draw.
For speed, ScrollRect is no faster (and maybe even a little slower) that a
CopyBits from an offscreen port/bitMap.  If the whole drawing is offscreen
somewhere, just shift your srcRect in relation to the scroll bars and do a
whole-window CopyBits.  It ain't lightning fast, but nothing scroll-wise is on
the Mac.

john calhoun

d88-jwa@byse.nada.kth.se (Jon W{tte) (03/16/91)

In article <> reiss@husc9.harvard.edu (Peter Reiss) writes:

   works, but does not look very good.  I have noticed that most programs
   seem to scroll graphics by shifting the current picture in one
   direction and drawing in the extra area.  How can I do this?

ScrollRect() - it also accumulates a region in a RegionHandle
which needs to be repainted.

Like this:

void
ScrollUpDown ( int amount )
{
	RgnHandle saveClip , updateClip ;
	Rect r ;

	r = thePort -> portRect ;
	updateClip = NewRgn ( ) ;
	saveClip = NewRgn ( ) ;
	if ( ! saveClip ) {
		DoSysErr ( MemError ( ) ) ;
	}

	ScrollRect ( & r , 0 , amount , updateClip ) ;

	/* Update variables according to scroll */

	GetClip ( saveClip ) ;
	SetClip ( updateClip ) ;

	DrawEverything ( ) ;

	SetClip ( saveClip ) ;

	DisposeRgn ( saveClip ) ;
	DisposeRgn ( updateClip ) ;
}

--
"The IM-IV file manager chapter documents zillions of calls, all of which
seem to do almost the same thing and none of which seem to do what I want
them to do."  --  Juri Munkki in comp.sys.mac.programmer

d88-jwa@cyklop.nada.kth.se (Jon W{tte) (03/18/91)

In article <1991Mar15.204959.29076@kuhub.cc.ukans.edu> 2fmlcalls@kuhub.cc.ukans.edu writes:

   For speed, ScrollRect is no faster (and maybe even a little slower) that a
   CopyBits from an offscreen port/bitMap.  If the whole drawing is offscreen

Except if you have an accelerated bit-blitting graphics card, that is...
That's why the traps are there, to allow future extensions to enhance
old programs too.

							h+@nada.kth.se
							Jon W{tte
--
"The IM-IV file manager chapter documents zillions of calls, all of which
seem to do almost the same thing and none of which seem to do what I want
them to do."  --  Juri Munkki in comp.sys.mac.programmer