mikeoro@hubcap.UUCP (Michael K O'Rourke) (02/02/89)
HEEELLLLLLPPPPPP!!!!!! I'm going insane here. And thus far apple has been no help whatsoever. I posted a request for information about CDEFs here and on AppleLink a couple weeks ago. I got a response on AppleLink, even though it did take a week, but it was a worthless answer. Therefore, I did some more investigating and have now narrowed my request to an easy answer. I am working with CDEFs and hear is my findings so far. (My CDEF is a specialized one part PICT button). If i give my button a return code corresponding to an indicator > 129 or so, then the Drag function in the CDEF gets called when I press on the button. This is no problem cause i can do all my highlighting there. However, it never sends the appropriate part code back to TrackControl. Thus, I don't know if the mouse was released in or out of the button; TrackControl always gets a zero back. If, on the other hand, I make the button a part, code <128 or so. Then drag never gets called. However, it seems that Draw gets called when i press the mouse inside the button. Does this mean that I must do the highlighting in the Draw function? (I don't want to use default highlighting because one of the CDEF options is no highlighting.) So is it necessary to do the highlighting in the Draw function? Is it possible to get TrackControl to return the correct part code/indicator code when i define the button as an indicator rather than a part? Please give me a simplistic answer and DON'T refer me to IM 328-332. I have reread thos pages over and over and still don't understand the problem. I also know that there is example code for the standard button on AppleLink. However, it is in assembly language and I don't know assembly language. I am using C and Pascal. Michael O'Rourke Clemson University
lim@iris.ucdavis.edu (Lloyd Lim) (02/02/89)
In article <4280@hubcap.UUCP> you write: >If i give my >button a return code corresponding to an indicator > 129 or so, then >the Drag function in the CDEF gets called when I press on the button. >This is no problem cause i can do all my highlighting there. However, it >never sends the appropriate part code back to TrackControl. Thus, I don't >know if the mouse was released in or out of the button; TrackControl >always gets a zero back. > >If, on the other hand, I make the button a part, code <128 or so. Then >drag never gets called. However, it seems that Draw gets called when i >press the mouse inside the button. Does this mean that I must do the >highlighting in the Draw function? (I don't want to use default >highlighting because one of the CDEF options is no highlighting.) > >So is it necessary to do the highlighting in the Draw function? Is >it possible to get TrackControl to return the correct part code/indicator >code when i define the button as an indicator rather than a part? I missed the original question but I think I can answer you. Yes, the highlighting is done in the Draw routine. This is the correct place. You sholdn't be doing anything with an indicator or in the Drag unless you actually have an indicator. If the param to Draw is 0, you draw the whole button normally. If the param to Draw is inButton (I think, I don't have references with me), you invert the button. If one of the options is no highlighting, you just check the variation code and if it's one for no highlighting, don't invert it. Actually, these days with color, instead of xoring stuff to invert, you have to switch the foreground and background colors and redraw the thing you're inverting. I hope I'm making sense. I don't really know what special thing you're trying to do. You can mail me if you have more questions. +++ Lloyd Lim Internet: lim@iris.ucdavis.edu Compuserve: 72647,660 US Mail: 146 Lysle Leach Hall, U.C. Davis, Davis, CA 95616
ech@pegasus.ATT.COM (Edward C Horvath) (02/03/89)
From article <3598@ucdavis.ucdavis.edu>, by lim@iris.ucdavis.edu (Lloyd Lim): [advising how to hilight a control] > ... Actually, these > days with color, instead of xoring stuff to invert, you have to switch the > foreground and background colors and redraw the thing you're inverting. There's a built-in flag to do this: see IM V-61. If you BitClr (Ptr (HiliteMode,pHiliteBit); or, in C, (*(char*)0x938) &= 0x7F; or, in assembler, bclr #7,$938 just before an InvertXXX operation, or drawing with srcXor mode, QD will swap the Hilite color (chosen in the Color cdev) and the background color. The degenerate case of one-bit-per-pixel works "exactly like inversion, and is compatible with all versions of Quickdraw." But QD resets the bit after each operation, so you have to continually clear it. My remaining question is why Apple didn't leave the bit CLEAR by default; seems to me that most apps would prefer the kinder, gentler effect obtained with hilitemode. (Despite it's colorful icons, I found that GunShy looks much better using hilitemode; simple inversion is rarely pleasing in color). =Ned Horvath=