Path: utzoo!utgpu!watserv1!watmath!att!rutgers!usc!samsung!uunet!munnari.oz.au!uniwa!vaxa.cc.uwa.oz.au!d_volaric From: d_volaric@vaxa.cc.uwa.oz.au Newsgroups: comp.sys.mac.programmer Subject: Re: Quickdraw bug Message-ID: <1990Jul13.210718.1961@vaxa.cc.uwa.oz.au> Date: 13 Jul 90 13:07:18 GMT References: <1990Jul4.023022.10833@eng.umd.edu> Organization: University of Western Australia Lines: 33 In article <1990Jul4.023022.10833@eng.umd.edu>, russotto@eng.umd.edu (Matthew T. Russotto) writes: > OK, here goes. I tried to post this once before, but it didn't seem to make > it. Basically the problem occurs with long, thin, single bit bitmaps. > tmpport = NewPtr((long)sizeof(GrafPort)); > OpenPort(tmpport); > bm.baseAddr = NewPtr(0xC000L/8L); > bm.rowBytes = (short)(0xC000L/8L); > bm.bounds.left = -24576; > bm.bounds.top = 0; > bm.bounds.right = 0x6000; > bm.bounds.bottom = 1; > SetPortBits(&bm); > BlockMove(&bm.bounds, &tmpport->portRect, (long)sizeof(Rect)); > RectRgn(tmpport->visRgn, &bm.bounds); > ClipRect(&bm.bounds); > EraseRect(&bm.bounds); > ^^^^^^^^ hangs here, at the eraserect. > Sure, this is a horrible abuse of Quickdraw, but QD should perform up to spec. What do you expect? Deep inside QuickDraw, it calculates the width of the rect, and uses it for its own private magic. This happens long after the code has given up on range checking, and the result is put into an integer. Lets calculate the width of your rect, and see what we get... $6000-(-$6000)=$C000= -$4000!!!!! Whats this? drawing a negative width rect into a negative width grafport? I'm suprised you got away with a mere crash! John ------------------------------------------------------------------------------- D V O R A K C O M P U T E R Phone : +61 9 330 2876 The Bunker, Rear 57 Holman Street, Alfred Cove, Western Australia, 6154. P.O. Box 315, Melville, WA, 6156. -------------------------------------------------------------------------------