time@tbomb.ice.com (Tim Endres) (01/02/91)
I have long been satisfied with simple routines called "focus" and "unfocus" that would let me move from port to port in my applications without much interference. Now, however, I have run into a case where I wish I could save the clipping of a port, and restore it later. I see no standard mathod mentioned in IM concerning this function. I presume that saving the ClipRgn handle in the port and replacing it afterwards is the approach, but hadn't thought through what other needs I must address. Has anyone solved this problem? Suggestions? tim
tim@hoptoad.uucp (Tim Maroney) (01/02/91)
In article <1CE00001.csbntk@tbomb.ice.com> time@tbomb.ice.com writes: >Now, however, I have run into a case where I wish I could save the >clipping of a port, and restore it later. I see no standard mathod >mentioned in IM concerning this function. I presume that saving the >ClipRgn handle in the port and replacing it afterwards is the approach, >but hadn't thought through what other needs I must address. GetClip/SetClip (IM I-166-7) -- Tim Maroney, Mac Software Consultant, sun!hoptoad!tim, tim@toad.com "I may be nuts but a speedfreak I ain't!" -- Robert Crumb
emmayche@dhw68k.cts.com (Mark Hartman) (01/03/91)
In article <1CE00001.csbntk@tbomb.ice.com> time@tbomb.ice.com writes: >Now, however, I have run into a case where I wish I could save the >clipping of a port, and restore it later. I see no standard mathod >mentioned in IM concerning this function. I presume that saving the >ClipRgn handle in the port and replacing it afterwards is the approach, >but hadn't thought through what other needs I must address. The simplest way to do this is with the GetClip() and SetClip() routines (IM-I-166,167); in fact, "preserving the current clipRgn" is specifically mentioned as the purpose of these calls. -- Mark Hartman, N6BMO "What are you just standing there for? Where Applelink: N1083 or BINARY.TREE do you think you are, DIS-ney World??" Internet: emmayche@dhw68k.cts.com -- General Knowledge, from uucp: ...{spsd,zardoz,felix}!dhw68k!emmayche CRANIUM COMMAND
keith@Apple.COM (Keith Rollin) (01/03/91)
In article <1CE00001.csbntk@tbomb.ice.com> time@tbomb.ice.com writes: > >I have long been satisfied with simple routines called "focus" and >"unfocus" that would let me move from port to port in my applications >without much interference. > >Now, however, I have run into a case where I wish I could save the >clipping of a port, and restore it later. I see no standard mathod >mentioned in IM concerning this function. I presume that saving the >ClipRgn handle in the port and replacing it afterwards is the approach, >but hadn't thought through what other needs I must address. > >Has anyone solved this problem? Suggestions? Tim, Two other people have suggested that you look into SetClip and GetClip. However, your use of the term "focus" suggests that you are using MacApp. If that's the case, then you can use GetFocus and SetFocus (be sure to allocate the clipRgn in the FocusRec first!). -- ------------------------------------------------------------------------------ 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
Lawson.English@p88.f15.n300.z1.fidonet.org (Lawson English) (01/07/91)
Tim Endres writes in a message to All
TE> I see no standard mathod mentioned in IM concerning this function.
TE> I presume that saving the ClipRgn handle in the port and replacing
TE> it afterwards is the approach, but hadn't thought through what
TE> other needs I must address.
GetClip/SetClip are documented on pages 166/167 of Inside Mac Vol 1...
"GetClip and SetClip are used to preserve tghe current clipRgn (they're
analgous
to GetPort and SetPort)." (IM Vol 1, page 167).
Lawson
--
Uucp: ...{gatech,ames,rutgers}!ncar!asuvax!stjhmc!300!15.88!Lawson.English
Internet: Lawson.English@p88.f15.n300.z1.fidonet.orgoster@well.sf.ca.us (David Phillip Oster) (01/07/91)
The update procedure for most of my panes just draws the frame, and
recursively calls the update procedure in each of the sub-panes.
Each sub pane does a :
if(ClippedOff()){
return;
}
to avoid time-consuming drawing that won't show anyway.
Each sub-pane sets the clip to the intersection of the old clip and the
size of the sub-pane, and restores the clip when the update is finished.
I use:
/* RestrictClipRgn - set clip to intersection of old and new, and return old.
*/
public RgnHandle RestrictClipRgn(rgn)RgnHandle rgn;{
RgnHandle oldClip, smallClip;
oldClip = NewRgn();
smallClip = NewRgn();
GetClip(oldClip);
SectRgn(thePort->clipRgn, rgn, smallClip);
SetClip(smallClip);
DisposeRgn(smallClip);
return oldClip;
}
/* RestrictClipRect - set clip to intersection of old and new, and return old.
*/
RgnHandle oldClip, smallClip;
smallClip = NewRgn();
oldClip = RestrictClipRgn(smallClip);
DisposeRgn(smallClip);
return oldClip;
}
Which is fine, except for the outermost pane of the window. It uses:
/* RestrictVisClipRgn - set clip to intersection of old and new, and return old.
also clip off the visRgn
*/
private RgnHandle RestrictVisClipRgn(rgn)RgnHandle rgn;{
RgnHandle oldClip, smallClip;
oldClip = NewRgn();
smallClip = NewRgn();
GetClip(oldClip);
SectRgn(thePort->clipRgn, rgn, smallClip);
SectRgn(thePort->visRgn, smallClip, smallClip);
SetClip(smallClip);
DisposeRgn(smallClip);
return oldClip;
}
/* RestrictVisClipRect - set clip to intersection of old and new, and return
old.
also clip off the visRgn
*/
public RgnHandle RestrictVisClipRect(r)Rect *r;{
RgnHandle oldClip, smallClip;
smallClip = NewRgn();
RectRgn(smallClip, r);
oldClip = RestrictVisClipRgn(smallClip);
DisposeRgn(smallClip);
return oldClip;
}
So that if the window is partially obscured by another, the visRgn will be
taken into account, by ClippedOff().
You should also do a SetOrigin() so each pane can have a local coordiante
system starting at (0,0), and once again, you should set it on entry,
and restore the old value on exit. If you don't call SetOrigin, then
patteern fills after a small horizontal scroll are not likely to line up
correctly.
Clear?
--
-- David Phillip Oster - At least the government doesn't make death worse.
-- oster@well.sf.ca.us = {backbone}!well!osterkaufman@Neon.Stanford.EDU (Marc T. Kaufman) (01/07/91)
In article <22461@well.sf.ca.us> oster@well.sf.ca.us (David Phillip Oster) writes:
.The update procedure for most of my panes just draws the frame, and
.recursively calls the update procedure in each of the sub-panes.
.Which is fine, except for the outermost pane of the window. It uses:
.
./* RestrictVisClipRgn - set clip to intersection of old and new, and return old.
. also clip off the visRgn
.
.So that if the window is partially obscured by another, the visRgn will be
.taken into account, by ClippedOff().
I am under the impression that all drawing is AUTOMATICALLY clipped to the
visRgn. My preference is to set the outermost clip region to portRect, to
keep it rectangular for faster checking. If visRgn is complex you may have
to endure more complex checking (i.e. checking essentially the same region
twice) when drawing in the visible area.
Marc Kaufman (kaufman@Neon.stanford.edu)oster@well.sf.ca.us (David Phillip Oster) (01/10/91)
In article <1991Jan6.225428.10958@Neon.Stanford.EDU> kaufman@Neon.Stanford.EDU (Marc T. Kaufman) writes: _>In article <22461@well.sf.ca.us> oster@well.sf.ca.us (David Phillip Oster) writes: _>.So that if the window is partially obscured by another, the visRgn will be _>.taken into account, by ClippedOff(). _> _>I am under the impression that all drawing is AUTOMATICALLY clipped to the _>visRgn. My preference is to set the outermost clip region to portRect, to _>keep it rectangular for faster checking. If visRgn is complex you may have _>to endure more complex checking (i.e. checking essentially the same region _>twice) when drawing in the visible area. _> The DRAWING is automaticvally clipped, but I want to avoid wasting the CPU time to call routines that won't do anything. -- -- David Phillip Oster - At least the government doesn't make death worse. -- oster@well.sf.ca.us = {backbone}!well!oster