time@ice.com (Tim Endres) (05/01/91)
I have a program which allows you to drag objects from one window to another. The program uses the DragGrayRgn() procedure to do the dragging of an outline of the objects, while using the "Drag Procedure" of the DragGrayRgn() call to implement the code that tracks the objects and highlights active targets they pass over. Of course, during this dragging of the objects, the target objects are highlighted and unhighlighted as the gray outline passes over them using some type of "inversion". Now, with color I am using the global gHiliteMode bit to indicate that the "inversion" should use the current "hilite color". This is fine, as the InvertRect() and like calls use the nice color I selected in the Color Control Panel item. HOWEVER, when I am dragging the gray region around, and I pass over one object that is highlighted to the next one, so that the highlighted targets *change* *UNDERNEATH* the dragged gray rgn, then I get all these little lines left all over the place. It appears that the inversion has changed the context underneath the region and when it is XOR-ed during the dragging it doesn't do what it is supposed to. I have tried to invert the dragged gray rgn at the begginning and end of my drag procedure, but that seems to leave more garbge all over the place. I also notice that the Finder handles this same case perfectly. Anyone know the secret? ------------------------------------------------------------- Tim Endres | time@ice.com ICE Engineering | uupsi!ice.com!time 8840 Main Street | Voice FAX Whitmore Lake MI. 48189 | (313) 449 8288 (313) 449 9208
deadman@garnet.berkeley.edu (Ben Haller) (05/05/91)
I wonder if anyone notices when I have my "readnews day" from the fact that there are maybe ten posts in a (approximate) row on each of the groups I read... :-> In article <1CE00001.ei5m1b@tbomb.ice.com> time@ice.com writes: > I have a program which allows you to drag objects from one >window to another. The program uses the DragGrayRgn() procedure > Now, with color I am using the global gHiliteMode bit to indicate >that the "inversion" should use the current "hilite color". This is > HOWEVER, when I am dragging the gray region around, and I pass over >one object that is highlighted to the next one, so that the highlighted >targets *change* *UNDERNEATH* the dragged gray rgn, then I get all >these little lines left all over the place. It appears that the inversion >has changed the context underneath the region and when it is XOR-ed >during the dragging it doesn't do what it is supposed to. > >Anyone know the secret? Well, since you mention "the Finder does this perfectly" I have to wonder exactly what you're talking about. It looks to me like, as far as DragGrayRgn is concerned, the Finder completely ignores the current highlight color. And well it should, it would have the same problem you're having if it tried. The problem is that the DragGrayRgn routine depends on xor working like xor, not like some bizarre half-breed created by setting the hilite bit and thereby driving QuickDraw out of its poor little mind. The operation must be reversible, i.e. a xor b xor b must equal a. When you set the hilite bit you mess this up, since you've told QuickDraw to perform a non-reversible operation. So you get garbage on your screen. No surprise. This isn't what the hilite color is supposed to be used for anyway. So don't...you know, just *don't*. -Ben Haller (deadman@garnet.berkeley.edu) "Jane says / She's never been in love She don't know what it is / Only knows if someone wants her..." - Jane's Addiction
time@ice.com (Tim Endres) (05/06/91)
In article <1991May4.232051.13698@agate.berkeley.edu>, deadman@garnet.berkeley.edu (Ben Haller) writes: > Well, since you mention "the Finder does this perfectly" I have to wonder > exactly what you're talking about. It looks to me like, as far as > DragGrayRgn is concerned, the Finder completely ignores the current > highlight color. And well it should, it would have the same problem you're > having if it tried. This is not true on my machine. The icon highlights in black, but the text is in the current hilite color. And it works. I have now discovered that the Finder does not call DragGrayRgn0() but implements one for itself. > The problem is that the DragGrayRgn routine depends on xor working like > xor, not like some bizarre half-breed created by setting the hilite bit and > thereby driving QuickDraw out of its poor little mind. The operation must > be reversible, i.e. a xor b xor b must equal a. When you set the hilite > bit you mess this up, since you've told QuickDraw to perform a > non-reversible operation. So you get garbage on your screen. No surprise. > This isn't what the hilite color is supposed to be used for anyway. So > don't...you know, just *don't*. Turns out that the problem is simply the changing of the screen bits between invocations of DragGrayRgn0()'s FrameRgn() calls. I then had the drag region framed at the beginning and end of my drag proc and all was fine. Except on subtle point. When the cursor got close to the edge of the screen, the region would quit being framed (disappear), but my routine couldn't tell. So I wrote a DragGrayRgn() that doesn't hide the region and all works fine now. tim. ------------------------------------------------------------- Tim Endres | time@ice.com ICE Engineering | uupsi!ice.com!time 8840 Main Street | Voice FAX Whitmore Lake MI. 48189 | (313) 449 8288 (313) 449 9208
lsr@Apple.com (Larry Rosenstein) (05/07/91)
In article <1991May4.232051.13698@agate.berkeley.edu>, deadman@garnet.berkeley.edu (Ben Haller) writes: > > be reversible, i.e. a xor b xor b must equal a. When you set the hilite > bit you mess this up, since you've told QuickDraw to perform a > non-reversible operation. You are right about the interaction between hilite mode and regular XOR. But I believe that hilite mode is also reversible operation, since it exchanges the background and hilite colors. But you can't interleave hilite and XOR drawing and expect to get the original display.