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=
mikeoro@hubcap.UUCP (Michael K O'Rourke) (02/07/89)
Okay, here we go again. But first I'd like to thank all who responded to my earlier problems, you really did help a lot. I am writing a PICT button control definition function (CDEF). Thanx to the previous responses to my questions, and a lot of hard word, I was able to figure out that my button needed to return a value <128 in the Test function. I chose 22. I also figured out that my CDEF needed to do its highlighting in the Draw Function since i have special highlighting. I went and made these changes, except for the highlighting, and everything worked great. TrackControl would return a 22 if i let go within the button and a 0 otherwise. However, when I put in my tracking code into Draw, things got weird. Now TrackControl always returns a 22. Whatz up? My Tracking code is very simple: high := 0; while StillDown do begin GetMouse(MLoc); if (high and not PtInRect(MLoc,theControl^^.contrlRect)) then begin high := false; invertRect(theControl^^.contrlRect); end else if (not high and PtInRect(MLoc,theControl^^.contrlRect)) then begin high := true; invertRect(theControl^^.contrlRect); end; end; if high then invertRect(theControl^^.contrlRect); Does anyone see anything wrong with this? Could using StillDown be messing with some globals that screw up TrackControl or the value that the CDEF returns?I just don't understand why adding this little chunk of code completely messes up the value returned to TrackControl. Desperately awaiting a logical reply, Michael O'Rourke
mikeoro@hubcap.UUCP (Michael K O'Rourke) (02/09/89)
Well, I finally got all my problems, almost, figured out with my PICT button CDEF. However, I have one last problem. It seems that my tester program which brings up a window with the control bombs on KillControls(MainPtr). Everything else works okay. It highlights and redraws and everything, but when it goes to dispose of the button i get an out of memory error. Anybody have any ideas? The tester program is in LSP. The same program in LSC doesn't bomb though. If anyone is willing to help I will be more than happy to send source for the control and the tester program. Thanks, Michael O'Rourke P.S. I would recommend writing a CDEF to everyone. Boy does it make you appreciate Macintosh programming and its complexities!!! .