Jump to content

GreSetBitmapBits

From EDM2
Revision as of 17:38, 30 November 2019 by Martini (talk | contribs) (Created page with "GreSetBitmapBits transfers bit-map data from application storage into the specified bit map or DC. This function must be supported by the presentation driver. GreSetBitmapBi...")
(diff) ← Older revision | Latest revision (diff) | Newer revision → (diff)

GreSetBitmapBits transfers bit-map data from application storage into the specified bit map or DC.

This function must be supported by the presentation driver. GreSetBitmapBits is called from the function GpiSetBitmapBits, and is used to transfer bit-map data from the device context to application storage. This function can be handled by bit-map simulation.

Simulation support
None. This function is mandatory for all drivers.

Syntax

GreSetBitmapBits(hdc, hbm, lScanStart, cScanCount, pBitmap, pInfo, pInstance, lFunction);

Parameters

hdc (HDC) - input
Device context handle.
hbm (HBITMAP) - input
Bit-map handle.
lScanStart (LONG) - input
Scan line number from where data transfer starts.
0 is the first.
cScanCount (LONG) - input
Number of scan lines to be transferred.
pBitmap (PBYTE) - input
Pointer to bit-map data.
Pointer to the pel data of the bit map. This data is stored in the order that the coordinates appear on a display screen, that is, the pel in the lower-left corner is the first in the bit map. Pels are scanned to the right and upward from that position. The bits of the first pel are stored beginning with the most significant bits of the first byte. The data for pels in each scan line is packed together tightly. However, all scan lines are padded at the end so that each one begins on a ULONG boundary. That is, three bytes of pel data will hold one 24-bit pel, three 8-bit pels, six 4-bit pels, or twenty-four 1-bit pels. If those three bytes are the only pel data for that scan line, one more byte of zeros would be required to pad the line to a ULONG boundary.
pInfo (PBITMAPINFO) - input
Pointer to BITMAPINFO or BITMAPINFO2 structure.

Pointer to either a BITMAPINFO structure:

cbFix Length of structure cx Bit-map width cy Bit-map height cPlanes Number of color planes, 1 if standard format cBitCount Number of adjacent color bits per pel argbColor[] Color table array of RGB structures: bBlue bGreen bRed

or pointer to a BITMAPINFO2 structure:

cbFix Length of structure

cx Bit-map width

cy Bit-map height

cPlanes Number of planes, 1 if standard format

cBitCount Number of adjacent color bits per pel

ulCompression Compression scheme used to store the bit map:

BCA_UNCOMP Bit map is uncompressed (the only valid value).

cbImage Length of bit-map storage data in bytes. If the bit map is uncompressed, 0 (default) can be specified for this.

cxResolution Horizontal component of the resolution of the target device; that is, the resolution of the device the bit map is intended for in the units specified by usUnits. This information enables an application to select from a resource group the bit map that best matches the characteristics of the current output device.

cyResolution Vertical component of the resolution of the target device; that is, the resolution of the device the bit map is intended for in the units specified by usUnits. This information enables an application to select from a resource group the bit map that best matches the characteristics of the current output device.


cclrUsed The number of color indexes from the color table that are used by the bit map. If it is 0 (the default), all the indexes are used. If it is not zero, only the first cclrUsed entries in the table are accessed by the system; further entries can be omitted.

For standard formats with a cBitCount of 1, 4, or 8 (and cPlanes=1), any indexes beyond cclrUsed are not valid. For example, a bit map with 64 colors can use the 8-bitcount format without having to supply the other 192 entries in the color table. For the 24-bitcount standard format, cclrUsed is the number of colors used by the bit map.

cclrImportant Minimum number of color indexes for satisfactory appearance of the bit map. More colors can be used in the bit map but it is not necessary to assign them to the device palette. These additional colors can be mapped to the nearest colors available. Zero (default) means that all entries are important. For a 24-bitcount standard format, the cclrImportant colors are also listed in the color table relating to this bit map.

usUnits Units of measure of the horizontal and vertical components of resolution:

BRU_METRIC (Default) Pels per meter.

usReserved Reserved field. If present, it must be 0.

usRecording Recording algorithm, the format in which bit-map data is recorded:

BRA_BOTTOMUP (Default) Scan lines are recorded from bottom to top.

usRendering Halftoning algorithm used to record bit-map data that has been digitally halftoned:

BRH_NOTHALFTONED (Default) Bit-map data not halftoned.

BRH_ERRORDIFFUSION Error diffusion or damped error diffusion algorithm

BRH_PANDA Processing algorithm for noncoded document acquisition

BRH_SUPERCIRCLE Super circle algorithm

cSize1 Size value 1. If BRH_ERRORDIFFUSION is specified in usRendering, cSize1 is the error damping as a percentage in the range 0 - 100. A value of 100% indicates no damping. A value of 0% indicates that any errors are not diffused.

If the BRH_PANDA or BRH_SUPERCIRCLE is specified, cSize1 is the X-dimension of the pattern used in pels.


cSize2 Size value 2. If BRH_ERRORDIFFUSION is specified in usRendering, this parameter is ignored. If the BRH_PANDA or BRH_SUPERCIRCLE is specified, cSize2 is the Y-dimension in pels of the pattern used.

ulColorEncoding Color encoding:

BCE_RGB (Default) Each element in the color array is an RGB2 data type.

ulIdentifier Reserved for application use.

argbColor[] Color table array of RGB2 structures:

bBlue bGreen bRed fcOptions Reserved. Must be 0.

pInstance (PVOID) - input
Pointer to instance data.
lFunction (ULONG) - input
High-order WORD=flags; low-order WORD=NGreSetBitmapBits.

Returns

rc (LONG) - returns
Return codes.

On completion, the handling routine must return a LONG value (lLines), indicating the number of lines transferred, or GPI_ALTERROR if an error occurred.

Possible Errors Detected: When an error is detected, the handling routine must call WinSetErrorInfo to post the condition. Error codes for conditions that the handling routine is expected to check include:

  • PMERR_BITMAP_NOT_SELECTED
  • PMERR_DEV_FUNC_NOT_INSTALLED
  • PMERR_INCORRECT_DC_TYPE
  • PMERR_INV_HBITMAP
  • PMERR_INV_IN_AREA
  • PMERR_INV_IN_PATH
  • PMERR_INV_INFO_TABLE
  • PMERR_INV_LENGTH_OR_COUNT
  • PMERR_INV_SCAN_START

Refer to the "Error Explanations" section in the Presentation Manager Programming Reference for further explanation.

Sample

#define INCL_GRE_BITMAPS
#include <os2.h>

HDC            hdc;         /*  Device context handle. */
HBITMAP        hbm;         /*  Bit-map handle. */
LONG           lScanStart;  /*  Scan line number from where data transfer starts. */
LONG           cScanCount;  /*  Number of scan lines to be transferred. */
PBYTE          pBitmap;     /*  Pointer to bit-map data. */
PBITMAPINFO    pInfo;       /*  Pointer to BITMAPINFO or BITMAPINFO2 structure. */
PVOID          pInstance;   /*  Pointer to instance data. */
ULONG          lFunction;   /*  High-order WORD=flags; low-order WORD=NGreSetBitmapBits. */
LONG           rc;          /*  Return codes. */

rc = GreSetBitmapBits(hdc, hbm, lScanStart,
       cScanCount, pBitmap, pInfo, pInstance,
       lFunction);

Remarks

When the bit-map handle is NULL, the DC must be a memory DC with a bit map currently selected. Otherwise, the DC must be valid for that device. When the format of the supplied bit map does not match that of the device, the handling routine must use the supplied BITMAPINFO or BITMAPINFO2 structure to convert it. Only standard formats and device formats that are compatible with the target device are supported.

Retrieved from "https://www.edm2.com/index.php?title=GreSetBitmapBits&oldid=66066"