All Databases Inside Mac - Basic Toolbox

OpenCPort

void OpenCPort( whichPort );

CGrafPtr whichPort ; pointer to a CGrafPort structure

OpenCPort initializes fields for a new CGrafPort, allocates memory for all

structures, and and then calls InitCPort to initialize them. The new

structures are the portPixMap, pnPixPat, fillPixPat, bkPixPat, and grafVars

(shown below).

whichPort is a CGrafPtr (pointer to a 108-byte CGrafPort

structure).

Returns: none

Notes: You normally won't need to use OpenCPort, since the Window Manager calls

this function when you create a window via NewCWindow,

GetNewCWindow,. and Dialog Manager. Also, if the old routines,

GetNewWindow, GetNewDialog, Alert, StopAlert, NoteAlert, and

CautionAlert, contain the resources 'wctb', 'dctb', or 'actb' they will

create a CGrafPort.

If used, the typical sequence is:

myPortPtr = ( CGrafPtr ) NewPtr( sizeof( CGrafPort ) );

OpenCPort( myPortPtr );

Use CloseCPort to dispose of the memory allocated. As above, the Window

Manager does this for you when you close a window.

CGrafPort is the same size as GrafPort and most of the fields are

un changed. However, a 4-byte PixMapHandle ( portPixMap ) has taken the

place of the old-style14-byte BitMap record that was embedded in the

GrafPort. The 10 bytes thus freed have been assigned to such new fields as

portVersion, which tells whether the port is a cGrafPort or an old-style

grafPort. The rest of the CGrafPort's structure looks like this:

Field Data Type Initial Setting

device short device ID for font selection

portPixMap PixMapHandle handle to the ports pixel map

portVersion short two highest bits always set

grafVars Handle see below

chExtra short 0

pnLocHFrac short initial pen fraction is one-half

portRect Rect port rectangle

visRgn RgnHandle handle to a rectangular region covering

screenBits.bounds (a global variable)

clipRgn RgnHandle handle to a rectangular region covering

(-32767,-32767) to (32767, 32767)

bkPixPat PixPatHandle handle to background pattern

rgbFgColor RGBColor field contains requested foreground color

rgbBkColor RGBColor field contains requested background color

pnLoc Point (0,0)

pnSize Point (1,1)

pnMode short patCopy (8)

pnPixPat PixPatHandle handle to pixel pattern

filPixPat PixPatHandle handle for internal use only

pnVis short 0 ( visible)

txFont short 0 (system font; e.g., chicago)

txFace Style plain (0)

txMode short srcOr (2)

txSize short 0 (system font size; e.g., 12)

spExtra Fixed 0

fgColor long pixel value of foreground color (supplied by

Color Manager as best match for rgbFgColor)

bkColor long pixel value of background color (supplied by

Color Manager as best match for rgbBkColor)

colrBit short reserved

patStretch short 0

picSave Handle NIL (0)

rgnSave Handle NIL (0)

polySave Handle NIL (0)

grafProcs CQDProcsPtr NIL (0)

GrafVars fields looks like this:

Field Data Type Initial Setting

rgbOpColor RGBColor black

rgbHiliteColor RGBColor default HiliteRGB

pmFgColor Handle 0

pmFgIndex short 0

pmBkColor Handle 0

pmBkIndex short 0

pmFlags short 0

Instead of being allocated its own color table, portPixMap takes the handle

( pixMapHandle) to the current device's color table when InitCPort is called.

The structure of pixMapHandle is shown below:

Field Device Initial setting

baseAddr Ptr A multiple of 4; pointer to first byte of pixel

image

rowBytes short offset to next row; high 3 bits are flags

15=1= pixMap, 15=0= bitMap; 14 =0 (not used);

13=0 (not used)

bounds Rect boundary rectangle

pmVersion short ColorQuickDraw version number (initially 0)

packType short Initially 0

packSize long Initially 0

hRes Fixed horizontal resolution in pixels per inch (72)

vRes Fixed vertical resolution (hRes = vRes = 72)

pixelType short 0 = chunky, 1= chunky/planar, 2 = planar (0

only, on Mac II)

pixelSize short always a power of 2 -- physical bits per pixel

cmpCount short 1

cmpSize short cmpSize = pixelSize

planeBytes long 0

pmTable CTabHandle Handle to color table (device or image)

pmReserved long 0 ( reserved)

Yet another handle used in the structure of the color graphics port is the

pixPatHandle. This is because the old GrafPort fields, pnPat, bkPat, and

fillPat have given way to pixel pattern (PixPat) fields -- pnPixPat,

bkPixPat, fillPixPat. The format of the pixel pattern structure is:

Field Data type Initial setting

patType short 0=old-style, 1=full- color, 2=RGB

patMap pixMapHandle handle to map of pattern's pixel image

patData Handle handle to the pattern's pixel image

patXData Handle handle to internal, expanded pixel

image

patXValid short flags to patXData (-1 invalidates)

patXMap Handle handle to patXData (for internal use)

pat1Data Pattern 50% gray

The CTabHandle mentioned above is a handle to another structure, the

ColorTable, which is treated in more depth in the section, Color Manager.

For the sake of the present discussion and the fact that the CTabHandle is

referenced in the pixel pattern structure above, the ColorTable's structure

is outlined below:

Field Data Type Initial setting

ctSeed long unique identifier from table

ctFlags short 1 for device, 0 for pixMap

ctSize short number of color table entries -1

ctTable cSpecArray Array of ColorSpec--whose structure is:

Field Data Type Initial setting

value short pixel value of desired color

rgb RGBColor true color

The CGrafPort's fundamental building block for drawing in color is the

RGBColor record. It uses 16-bit unsigned integers to specify the intensity

values for the three primary colors--red, green, and blue (or RGB). The

translation from RGB values to pixel values takes place when the color is

actually drawn. The RGBColor record type looks like:

Field Data Type Initial setting

red unsigned short red component

green unsigned short green component

blue unsigned short blue component