jkeegan@hawk.ulowell.edu (Jeffrey Keegan) (10/11/88)
I am currently working on a terminal program. For various reasons (one of which being speed), I am not using Text Edit but instead I've created my own output routines. I've noticed a few problems that I have run into, but recently when I tested these problems on other programs (namely Microphone (version 1), Red Ryder (10.0), MiniTerm, and FModem) they are still there. The first problem was when a window was in the background, scrolling didn't work properly. Since then I have pretty much been able to get around the problem, so I won't bother with this one. The real problem that I'm having is this: If the window is dragged so that part of it is off the screen (and almost every application I've seen that allows dragging windows allows parts of them to be dragged off the screen), then scrolling can cause problems. Specific example: you move the text window so the bottom half is off the screen. Then you type enough text that the screen starts to scroll (I handle scrolling with scrollrect, and draw all drawings to both an on screen and off screen bitmap for update events), and it screws up. The text that is still visible on the screen scrolls up fine, but none of the text that was below the screen boundary scrolls up. In addition, usually garbage is scrolled up instead (if I play around with the visrgn and cliprgn fields of the grafport).. Also, playing around with those usually upsets the lower rounded corners of the screen. I need help.. Please reply if you have any idea how text scrolling should be handled in a window that is not entirely visible. ..Jeff Keegan jkeegan@hawk.ulowell.edu
usenet@cps3xx.UUCP (Usenet file owner) (10/15/88)
In article <9569@swan.ulowell.edu>, Jeffrey Keegan (jkeegan@hawk.ulowell.edu) writes: > If the window is dragged so that part of it is off the screen (and almost > every application I've seen that allows dragging windows allows parts of > them to be dragged off the screen), then scrolling can cause problems. > Specific example: you move the text window so the bottom half is off the > screen. Then you type enough text that the screen starts to scroll (I > handle scrolling with scrollrect, and draw all drawings to both an on > screen and off screen bitmap for update events), and it screws up. The > text that is still visible on the screen scrolls up fine, but none of the > text that was below the screen boundary scrolls up. This is a fairly common misconception about Macintosh windows. The only part of the window that contains data is the visible area--the window contents off-screen don't exist (unlike some other windowing systems, like the Amiga's [I think]). The trick is to keep the information in more than one place. Keep an array with the text in it (80x24, maybe). To scroll the window, you need to: 1. Call ScrollRect to update the visible portion. 2. Add the previously invisible portion to the update region. 3. Update the update region. You may want to update the previously invisible area directly, rather than relying on an update event (otherwise continuous scrolling would never update the screen). Red Ryder (10.3) delays the update, but eventually updates it (without necessarily waiting for a normal update event, I think--don't know details though, just how it appears). Hope this helps... Anton +----------------------------------+------------------------+ | Anton Rang (grad student) | "UNIX: Just Say No!" | | Michigan State University | rang@cpswh.cps.msu.edu | +----------------------------------+------------------------+
tim@hoptoad.uucp (Tim Maroney) (10/16/88)
Quoth Jeff Keegan: "you move the text window so the bottom half is off the
screen. Then you type enough text that the screen starts to scroll (I
handle scrolling with scrollrect, and draw all drawings to both an on
screen and off screen bitmap for update events), and it screws up. The
text that is still visible on the screen scrolls up fine, but none of the
text that was below the screen boundary scrolls up. In addition, usually
garbage is scrolled up instead (if I play around with the visrgn and
cliprgn fields of the grafport).. Also, playing around with those usually
upsets the lower rounded corners of the screen."
The problem is you're messing with the visRgn. Never, ever touch it! It
is the foundation of both the Window manager and MultiFinder's Layer
Manager. The only legitimate operations on the visRgn are read-only
operations -- for instance, sometimes you want to know if the window is
visible (as opposed to shown), so you can test the visRgn for emptiness;
also, you have to pass it to a list manager routine, which is dumb, but
there it is. Apple's current guidelines explicitly forbid messing about
with the visRgn.
The text below the screen boundary won't scroll up; if you read the ScrollRect
description, you will see that the area opened up is filled with the window's
background pattern (usually white). You have to fill in the area yourself.
If you pass the updateRgn of the window to ScrollRect, it will generate an
update event for that area and your ordinary update handling will take care
of it; but it's usually better just to pass a null region which you throw
away, and to fill in the region explicitly after the ScrollRect.
--
Tim Maroney, Consultant, Eclectic Software, sun!hoptoad!tim
"I wrapped a newspaper round my head, so I'd look like I was deep.
I said some mumbo-jumbos then: I told him he was going to sleep.
I robbed his ring, his pocket watch, and everything else I found.
I had that sucker hypnotized; he didn't even make a sound!"
- Frank Zappa, "Kozmik Debris"