philf@lindy.Stanford.EDU (Phil Fernandez) (07/04/89)
Hopefully someone can explain the following to me, and offer a solution. My application prepares an off-screen bitmap, and draws a fairly complex background image into it. Then, I open a window and use CopyBits to copy the background image to the active window grafPort. I use the off-screen bitmap because the image needs to be sized and srolled, and copying-in a rect from the bitmap seems much easier and faster than regenerating the image. Anyhow, this all works great. My problem comes when I overlay a TextEdit Rect on top of the image. Sequence looks like: <generate image off-screen> <New Window> <CopyBits to new window's grafport> <allocate text-edit record, destRect and viewRect == full window rect> I find that TextEdit blanks the each line into which I enter text. That is, if I start type into the first line of the TextEdit rect, that entire line is cleared to white, wiping out the background image I had placed there. Similarly, as I move down to subsequent lines, the full line is blanked as soon as I enter the line. I checked the pen mode for my TERec -- it's srcOr, which in theory should just OR bits into my image, not copy white bits. I want the textedit image to simply overlay the background image in my window, and not clear anything. Can anyone explain what's going on here? Am I being dumb, or is this some fact of life that I have to work around? Any help would be appreciated. phil
earleh@eleazar.dartmouth.edu (Earle R. Horton) (07/04/89)
In article <3705@lindy.Stanford.EDU> philf@lindy.UUCP (Phil Fernandez) writes: > >Hopefully someone can explain the following to me, and offer a solution. > >My application prepares an off-screen bitmap, and draws a fairly >complex background image into it. Then, I open a window and use >CopyBits to copy the background image to the active window grafPort. ... >My problem comes when I overlay a TextEdit Rect on top of the image. ... >I find that TextEdit blanks the each line into which I enter text. ... >I checked the pen mode for my TERec -- it's srcOr, which in theory This is because TextEdit calls EraseRect before calling DrawText. The srcOr mode is ORing bits into a freshly erased background! Since TextEdit leaves text on a blank background on the screen, you might try calling CopyBits in srcOr mode to restore your background after you call TextEdit. If your text display is being updated in response to typed-in characters, then this solution might be somewhat less than aesthetic. If you are allowing selection of text, and Cut/Copy/Paste into your TERec, then things could get downright ugly with this solution. Depending on what you are trying to achieve, you might have to use QuickDraw directly to get the effect you want. Earle R. Horton "People forget how fast you did a job, but they remember how well you did it." Salada Tag Lines
svc@well.UUCP (Leonard Rosenthol) (07/05/89)
In article <3705@lindy.Stanford.EDU>, philf@lindy.Stanford.EDU (Phil Fernandez) writes: > > Hopefully someone can explain the following to me, and offer a solution. > > [discussion of use of offscreen BM] > [problem overlaying a TextEdit Rect over a nifty bitmap] > > I find that TextEdit blanks the each line into which I enter text. > That is, if I start type into the first line of the TextEdit rect, > that entire line is cleared to white, wiping out the background image > I had placed there. > > Similarly, as I move down to subsequent lines, the full line is > blanked as soon as I enter the line. > > Can anyone explain what's going on here? Am I being dumb, or is this > some fact of life that I have to work around? Any help would be appreciated. > Guess what?? You've found one of the better FEATURES in TextEdit. It really is a feature and NOT a bug. If you disassemble TE (one of my more favorite hobbies :-) you will see that TEKey does an EraseRect from cursorPos to the end of the line (and depending of teSysJust that can either wipe left-> right or right->left). Why does TE do an eraseRect?? It is my understanding that the reason for this is that it makes doing text insertion/wrap much easier than the standard method of simply shifting everyting over with CopyBits. It is also one of the reasons why TE is SO SLOW...EraseRect for EVERY char!! However, given the age of TE, what do you expect?? The only solution that I can offer you, off hand, is to keep the TERect offscreen, and then TEUpdate into the main port. If the penMode and copyMode are correct when Updating you may be able to get away with out the white (since that only happens during text entry). You might also want to write your own TE, but that might be a bit more than you are looking for, eh?? Hope that helps.. -- +--------------------------------------------------+ Leonard Rosenthol | GEnie : MACgician Lazerware, inc. | MacNet: MACgician UUCP: svc@well.UUCP | ALink : D0025
oster@dewey.soe.berkeley.edu (David Phillip Oster) (07/05/89)
In article <14190@dartvax.Dartmouth.EDU> earleh@eleazar.dartmouth.edu (Earle R. Horton) writes: > This is because TextEdit calls EraseRect before calling DrawText. >The srcOr mode is ORing bits into a freshly erased background! But don't depend on this: It doesn't always call EraseRect(), so if you need it erased, you might have to do it yourself. Since you need it not erased, just aim the TERec at an offscreen GrafPort, and after each keystroke, CopyBits the background to a work offscreen GrafPort, CopyBits the text on top, and CopyBits the result to the screen. Since the first two CopyBits never need to worry about clipping, you can do them with Moves and Ors, or tight asssembly language Move.l & OR.l loops, or unroll the loops for more speed. To really go fast, use QuickDraw bottleneck procedures in the TE's offscreen port to keep track of the bound box that needs to be updated.
tim@hoptoad.uucp (Tim Maroney) (07/05/89)
TextEdit calls EraseRect before drawing a line. All you have to do to defeat it is to replace the rectProc QD bottleneck in the port you're drawing into. Have it ignore the "erase" GrafVerb and call the StdRect default bottleneck for every other GrafVerb. This ought to do the trick. -- Tim Maroney, Mac Software Consultant, sun!hoptoad!tim, tim@toad.com Postal: 424 Tehama, SF CA 94103; Phone: (415) 495-2934 "A book is the product of a contract with the Devil that inverts the Faustian contract, he'd told Allie. Dr Faustus sacrificed eternity in return for two dozen years of power; the writer agrees to the ruination of his life, and gains (but only if he's lucky) maybe not eternity, but posterity, at least. Either way (this was Jumpy's point) it's the Devil who wins." -- Salman Rushdie, THE SATANIC VERSES