astor@dev8j.mdcbbs.com (06/14/90)
Sorry about previous post, problems with my news process...
---------------------------------------------------------------
I'm running into a really bizzarre bug, and was wonderring if anyone
else has experienced it.
To start with, I'm using a Mac IIci, 8 bit color, 13 " monitor,
with Think C 4.0 as development environment.
My application has an offscreen pixmap, and I'm trying to copy the
pixmap onto the scrap as a simple PICT.
I use OpenPicture, CopyBits, ClosePicture, ZeroScrap, and PutScrap.
In my clipboard display, I use GetScrap, HLock, and DrawPicture.
In general, things work fine. The copy operation occurs, the clipboard
displays the correct picture, and other applications can use it.
In some cases, which I can duplicate quite easily, when the ClipBoard
tries to display the Picture, DrawPicture hangs, and the Heap gets
clobberred. I will then often get a clipboard image which is fine for the
first third to two thirds, and then shifted some for the rest.
The problem appears to be in creation of the Scrap, because other
applications will hang trying to read this scrap as well.
I modified my application so I could write the scrap being created to
a PICT format file. I then created two of these PICT files, one with
a working operation, and one with a crash operation. The picture in the
offscreen pixmap was identical. I ran the PICT files through a
comparison utility. Two differences showed up.
The PICT files are 1fA6 (8102) bytes in size ( plus 512 byte header ).
The rectangles used for all the operations is 0,0,300,300(decimal).
The opcodes are:
0011 02ff pict version 2
0c00 ffff ffff 0000 0000 0000 0000 012c 0000 012c 0000 0000 0000
header data
001e default hilite
0001 000a 0000 0000 012c 012c clip rectangle
0098 812c 0000 0000 012c 012c ... pack bits rectangle
00ff end of picture
The first difference was the pmTable field of the pixmap in the
pack bits opcode. I believe that this field is ignored.
The other difference was in the middle of the pixdata ( packed scanlines )
in the pack bits opcode. The good version had:
0000 2381 00ee 0000 2381 00ed 0001 2300 0010 0100 2381 00ee 0000 2381
and the bad version had:
0000 2381 00ee 0000 2381 00ed 0001 2300 0000 0e38 2381 00ee 0000 2381
I assume this is the problem, but don't know how it could possible occur.
Anyone got any ideas?
--
================================================================
| Andy Astor | Voice: (714) 952-5836 |
| McDonnell Douglas M&E | UUCP: uunet!mdcbbs!astor |
| Cypress, CA | Internet: astor@mdcbbs.com |
================================================================russotto@eng.umd.edu (Matthew T. Russotto) (06/15/90)
In article <1990Jun13.181220.1@dev8j.mdcbbs.com> astor@dev8j.mdcbbs.com writes: >My application has an offscreen pixmap, and I'm trying to copy the >pixmap onto the scrap as a simple PICT. > >I use OpenPicture, CopyBits, ClosePicture, ZeroScrap, and PutScrap. Try OpenPicture, CopyBits,ClosePicture,ZeroScrap,HLock,PutScrap. -- Matthew T. Russotto russotto@eng.umd.edu russotto@wam.umd.edu ][, ][+, ///, ///+, //e, //c, IIGS, //c+ --- Any questions?