wdh@well.UUCP (Bill Hofmann) (07/29/89)
Having just finished getting nailed by a few documentation failures, I figured I'd pass along the lessons learned. CalcCMask, SeedCFill -------------------- Turns out that not only is IM-V wrong, but the only place to figure out what is right is the MacDTS Q & A Stack. First, the matchProc is declared totally wrong. In reality, it's the same as any custom search proc, to wit: pascal Boolean matchProc(rgb, result) RGBColor * rgb; /* this is a VAR */ long * result; /* so is this */ In the case of SeedCFill and CalcCMask, result should always be either 1 (black) or 0 (white) and return value should be TRUE. The other thing that even the Q & A Stack is a little vague about is the rectangles you pass. Seems both routines call the Classic QD equivalents, which have rather bizarro parameters, so the end result is that if you want good results, you should be sure the left edge gets rounded down to the nearest multiple of 16 and the right edge gets rounded UP to the nearest multiple of 16. There's something else about coordinates of seedH and seedV for SeedCFill, basically that it uses the coordinate system of the current port. GWorld Stuff ------------ This set of code is really great, except for a monsterous bug (reported and acknowledged) and a little vagueness. The bug is, if you ever intend to call UpdateGWorld, you MUST MUST MUST allocate a grafProcs field, even if it's just filled with the defaults (by SetStdCProcs), because UpdateGWorld doesn't check if grafProcs is NIL before it dereferences and copies to a new grafProcs field. Pretty dumb, eh? The gotcha is that if UpdateGWorld has to mess with the GWorldPtr you pass it, it may change it, so if, like me, you keep it in a handle-based structure and copy it to a local variable to avoid memory shuffling, be sure to copy it back into the real storage for it. You don't have to do it in *every* case, but it doesn't hurt to do it every time. Hope these things help. -Bill