Unwanted transparency processing ... turn off?

[qwert]

Recently, I moved some bitmap images from being referenced disk files with statements like:

GUICtrlCreatePic(@ScriptDir & “Image.bmp", 100, 20, 200, 60)

to being installed in the EXE by AutoItWrapper’s Add File feature ... and then being displayed with ResourceEx UDF:

$hBmp = _Resource_Get(“IMAGE”, $RT_BITMAP)

_Resource_SetBitmapToCtrlID($Pic, $hBmp)

 

The file referencing worked fine. But lo and behold, some of the “embedded” bitmaps displayed with missing areas—transparent pixels. (BTW, my main GUI is not a layered GUI, which my understanding is that is required for transparent image effects.)

 

“Hmmm.” Then I remembered the about the “first pixel” method of displaying transparent images. A detailed investigation of exactly the color value of the pixels revealed they were all the same: 0xF0F0F0.  “Hmmm ... That’s the color of the default GUI background on Windows 7.”  Yet these exact bitmaps displayed fine when coming from their own BMP files.

 

Digging a little deeper (into ResourcesEx) I noted two things:

 • kernel32.dll and user32.dll calls are made to display the images

 • the wide(W) version of parameters are used in the calls. For example:

$aResult = DllCall("user32.dll", "handle", "LoadImageW", "handle", $hInstance, "wstr", $bmp, "uint", $IMAGE_BITMAP, "int", 0, "int", 0, "uint", 0)

 

Here’s an msdn reference:

https://msdn.microsoft.com/en-us/library/windows/desktop/ms648045%28v=vs.85%29.aspx?f=255&MSPPError=-2147217396

In particular, note the complexity of msdn’s description of the processing of the color parameters.

 

And here’s a discussion regarding the differences in the Wide and Normal parameters:

http://www.cplusplus.com/forum/articles/16820/

 

So, my questions are:

Is it possible that the last user32 call parameter (fuLoad [in]) is being misformatted?

And mainly:  Is it possible to entirely disable image transparency processing for a GUI?

 

I realize it’s almost impossible to figure some of these things out, so I’m not expecting a fix ... not really. But I wanted to bring this case to light just in case someone else encounters it.

 

I’ve worked around my immediate problem by changing all 0xF0F0F0 bits to 0xF0F0F1. But I would like to be able to turn off transparency processing completely to avoid any future problems.

 

Thanks in advance to anyone who is able to shed some light on this.

[UEZ]

@qwert: do you have a small reproducer?

[qwert]

Here's a small example using a gradient BMP.  The two "defects" are where the gradient passes through the 0xF0F0F0 color value.

#Region ;**** Directives created by AutoIt3Wrapper_GUI ****
#AutoIt3Wrapper_Res_Fileversion=1.1.1.1
#AutoIt3Wrapper_Res_requestedExecutionLevel=asInvoker
#AutoIt3Wrapper_Res_File_Add=D:\Au3 Scripts\My Forum Contribs\Test BMP.bmp, RT_BITMAP, IMAGE
#EndRegion ;**** Directives created by AutoIt3Wrapper_GUI ****

#include <GUIConstantsEx.au3>
#include <WindowsConstants.au3>
#include <ResourcesEx.au3>

$GUI = GUICreate("Transparency Test", 300, 200)
$Label = GUICtrlCreateLabel("", 20, 20, 240, 140)
GUICtrlSetBkColor(-2, 0x009999)
$Pic = GUICtrlCreatePic("", 100, 50, 90, 60)
$hBmp = _Resource_Get("IMAGE", $RT_BITMAP)
_Resource_SetBitmapToCtrlID($Pic, $hBmp)

GUISetState(@SW_SHOW)

While 1
    $GUIGetMsg = GUIGetMsg()
    Switch $GUIGetMsg
        Case $GUI_EVENT_CLOSE
        Exit
    EndSwitch
WEnd

Test BMP.bmp

[UEZ]

Well, _Resource_Get doesn't exists in ResourcesEx.au3. I have to use _Resource_GetAsBitmap instead but the result looks good for me.

Tested on Win 8.1 x64 using latest stable / beta.

[qwert]

Wow. 

The change you've made does work.

But I'm confused by it.

_Resource_Get() does exist in the copy of ResourcesEX.au3 that I have (v3.3.12.0, I thought) and is called immediately by _Resouce_GetAsImage() ... which is the function called immediately by _Resouce_GetAsBitmap():

Func _Resource_GetAsBitmap($sResNameOrID, $iResType = $RT_RCDATA, $sDLL = Default)
    Local $hImage = _Resource_GetAsImage($sResNameOrID, $iResType, $sDLL)
    Local $iError = @error
    Local $iLength = @extended
    Return SetError($iError, $iLength, (($iError = $RESOURCE_ERROR_NONE) ? _GDIPlus_BitmapCreateHBITMAPFromBitmap($hImage) : 0)) ; hBitmap type.
EndFunc   ;==>_Resource_GetAsBitmap
:
:
V
Func _Resource_GetAsImage($sResNameOrID, $iResType = $RT_RCDATA, $sDLL = Default)
    If $iResType = Default Then $iResType = $RT_RCDATA
    Local $vResource = _Resource_Get($sResNameOrID, $iResType, 0, $sDLL)
    Local $iError = @error
    Local $iLength = @extended

    Local $hImage = 0
    If $iError = $RESOURCE_ERROR_NONE And $iLength > 0 Then
        If $iResType = $RT_BITMAP Then
            ; $vResource is hBitmap type.
            $hImage = _GDIPlus_BitmapCreateFromHBITMAP($vResource)
        Else
            ; $vResource is memory pointer.
            Local $hData = _MemGlobalAlloc($iLength, $GMEM_MOVEABLE)
            Local $pData = _MemGlobalLock($hData)
            _MemMoveMemory($vResource, $pData, $iLength)
            _MemGlobalUnlock($hData)
            Local $pStream = _WinAPI_CreateStreamOnHGlobal($hData)
            $hImage = _GDIPlus_BitmapCreateFromStream($pStream) ; hImage type
            _WinAPI_ReleaseStream($pStream)
        EndIf
    EndIf
    Return SetError($iError, $iLength, $hImage)
EndFunc   ;==>_Resource_GetAsImage

Return _GDIPlus_BitmapCreateHBITMAPFromBitmap($hImage) seems to be the difference.

In what slight way does an HBITMAP differ from the bitmap in $hImage?  Both of them display, as we've shown.

I do appreciate that you've figured this out.  I'm just confused by what I'm seeing.

[UEZ]

The difference between $hHBitmap and $hImage is simple:

$hHBitmap is a GDI bitmap and

$hImage is a GDIPlus bitmap.

Both are not compatible with each other and GUI elements need a GDI bitmap not in GDIPlus format!

_GDIPlus_BitmapCreateHBITMAPFromBitmap creates a GDI bitmap from a GDIPlus bitmap which can be send to the control.

[qwert]

GUI elements need a GDI bitmap not in GDIPlus format!

I want to put that up in lights.

In 7 years of using AU3 and bitmaps, I've never seen that simple fact stated.

Thanks, UEZ, for making it clear.

Edited April 23, 2015 by qwert