C / C++ / MFC

Mark Salsbery wrote:

AFAIK, there's no alpha channel support in GDI.

Mark Salsbery wrote:

There's no BITMAPINFO type that represents 32-bit ARGB
format.

Mark Salsbery wrote:

AlphaBlend() is for DDBs

Mark Salsbery wrote:

but why, when GDI+ provides much more support?

Chris Losinger wrote:

a trivial matter to get from a DIB to an HBITMAP

Mark Salsbery
Microsoft MVP - Visual C++

<font color="Green">// FreeImage functions for Mark's reference :)
//FreeImage_GetWidth(pFIBitmap)
//FreeImage_GetHeight(pFIBitmap)
//FreeImage_GetBits(pFIBitmap)
//FreeImage_GetInfo(pFIBitmap)
//FreeImage_GetInfoHeader(pFIBitmap)</font>

LONG lImageWidth = FreeImage_GetWidth(pFIBitmap);
LONG lImageHeight = FreeImage_GetHeight(pFIBitmap);
WORD wBitsPerPixel = 32;
 
LONG lBytesPerRow = (((lImageWidth * (long)wBitsPerPixel + 31L) & (~31L)) / 8L);
 
BITMAPINFO bmi;
memset(&bmi, 0, sizeof(BITMAPINFO));
bmi.bmiHeader.biSize = sizeof(BITMAPINFOHEADER);
bmi.bmiHeader.biWidth = lImageWidth;
bmi.bmiHeader.biHeight = lImageHeight;
bmi.bmiHeader.biPlanes = 1;
bmi.bmiHeader.biBitCount = wBitsPerPixel;
bmi.bmiHeader.biCompression = BI_RGB;
bmi.bmiHeader.biSizeImage = lBytesPerRow * lImageHeight;
<font color="Green">//bmi.bmiHeader.biXPelsPerMeter = 0;
//bmi.bmiHeader.biYPelsPerMeter = 0;
//bmi.bmiHeader.biClrUsed = 0;
//bmi.bmiHeader.biClrImportant = 0;</font>

HDC hdc = ::CreateCompatibleDC(0);

BYTE* pBitmapBits;
 
HBITMAP hBitmap = ::CreateDIBSection(hdc, &bmi, DIB_RGB_COLORS, (void**)&pBitmapBits, NULL, 0);

if (hBitmap)
{   
    <font color="Green">//// Test - fill the DIBsection pixel data with arbitrary ARGB values
    //RGBQUAD *pCurPixel = (RGBQUAD *)pBitmapBits;
    //int PixelCount = lImageWidth * lImageHeight;
    //while (PixelCount > 0)
    //{
    //    (*pCurPixel).rgbRed =      0x00;
    //    (*pCurPixel).rgbGreen =    0x00;
    //    (*pCurPixel).rgbBlue =     0xA0;
    //    (*pCurPixel).rgbReserved = 0x80;  <font color="Red">//<--- per-pixel alpha channel value goes here</font>
    //    pCurPixel++;
    //    PixelCount--;
    //}</font>

    <font color="Green">// Copy freeimage pixel data to the DIBSection</font> <font color="Red">- NOTE!!! Assumes source image is 32-bit data and same size!!</font>
    memcpy(pBitmapBits, FreeImage_GetBits(pFIBitmap), bmi.bmiHeader.biSizeImage);

    HGDIOBJ hOldBitmap = ::SelectObject(hdc, hBitmap);

    HDC hClientDC = ::GetDC(hwndWindowToDrawOn);

    BLENDFUNCTION bf;
    bf.BlendOp = AC_SRC_OVER;
    bf.BlendFlags = 0;
    bf.SourceConstantAlpha = 0xFF;
    bf.AlphaFormat = AC_SRC_ALPHA;

    ::AlphaBlend(hClientDC, 0, 0, lImageWidth, lImageHeight,
                        hdc, 0, 0, lImageWidth, lImageHeight, bf);

    ::ReleaseDC(hwndWindowToDrawOn, hClientDC);
    ::SelectObject(hdc, hOldBitmap);
    ::DeleteObject(hBitmap);
}

::DeleteDC(hdc);

Mark Salsbery
Microsoft MVP - Visual C++

trioum wrote:

it changes the
alpha value of whole pixels not alpha channel that I wants.

Mark Salsbery
Microsoft MVP - Visual C++

CWnd* p = GetDlgItem(IDCANCEL);
p->EnableWindow(FALSE);

HWND h = ::GetDlgItem(hYourDlgHandle, IDCANCEL);
::EnableWindow(h, FALSE);

James R. Twine wrote:

I believe that the STL string object will not allocate storage until required or directly requested. So #3 should not be expected to throw an exception.

James R. Twine wrote:

heap corruption

James R. Twine wrote:

address space exhaustion

George_George wrote:

I am using Visual Studio. I am interested to find more information about whether in my specific version of STL implementation, for empty string, whether there will be any space allocation. But in file string, there is no constructor for basic_string. Do you know where to find it? (I believe I should look at the constructor for string, which is the same as the constructor for basic_string)

George_George wrote:

Is it structured exception or C++ exception? I belive it is structured exception. But I am talking about C++ exception.

George_George wrote:

You mean we reserved a lot of space in virtual memory, but not commit?

James R. Twine wrote:

I am not sure which version of VS you are talking about, but I am sure a simple find in files will locate it for you.

James R. Twine wrote:

AFAIK, that would depend on the type of heap corruption. Your heap could br corrupted such that it thinks that there are no more free blocks avaialble (if you use a non-growable heap), or its internal structured could be fulblungered such that when the heap code tries to use/evaluate them, it causes a crash.

George_George wrote:

I think you mean some meta data of heap, e.g. free space size of the heap is corrupted (so that the actual free memory size is not reflected), then when we allocate later, there will be bad_alloc exception?