Professional UI Solutions
Site Map   /  Register


Please Log In to post a new message or reply to an existing one. If you are not registered, please register.

NOTE: Some forums may be read-only if you are not currently subscribed to our technical support services.

Forums » Prof-UIS Tech Support » Problem with AlphaBend Collapse All
Subject Author Date
Krustys Donuts Jul 29, 2008 - 3:34 PM

Dear Support,

In my constructor of a CExtResizableDialog derived class I load a PNG file as follows:


//Load the PNG resources for this dialog.


m_bmpToolSpaceImage = _bmpTmp;

"C:\\source\\Studio 2008\\Plugins\\Ziggy\\res\\ToolSpaceImage.png")));


In my OnPaint handler I try to display this png image on the dialog as follows:



CPaintDC dc(

VRTabChildToolSpace::OnPaint()this); // device context for painting


//Get the desired location of the jog tool space image.

CRect rect;




//Draw the joint space jogging image.

m_bmpToolSpaceImage.AlphaBlend(dc.m_hDC, rect);


Unfortunately, I am not seeing any image on the display. Other png files loaded just as the ToolSpaceImage.png file show up fine on a CExtButton object. I hit a breakpoint in the OnPaint handler as would be expected. Is there an example of the AlphaBlend funciton being used. Am I doing anything wrong?






Krustys Donuts Aug 1, 2008 - 10:53 AM


You are correct, I am using resizable dialogs. I would like to describe why I want a clickable button on top of a CExtLabel object. On my interface there is an image of a robot gripper. This gripper is equiped with fingers that move in (to grasp) and out (to let go). The picture of the gripper originates from a PNG file and is displayed on the UI via a CExtLabel control (using SetBitmapEx). Via two buttons, I must allow the user to move the fingers of the gripper together and outward. These two buttons are CExtButton derived controls. I would like to position these buttons between the two fingers. Thus, the buttons must go on top of the CExtLabel that shows the gripper image. Is there a better approach to achieving this goal?


Technical Support Aug 1, 2008 - 12:54 PM

It looks like robot UI item in your application is enough specific UI item to code it from scratch. This robot window should be a complete stand-alone window. The buttons for controlling robot part movements should be a custom drawn parts of robot window. Of course, it’s possible to use static picture control as robot window and place push button windows over robot picture window using the SetWindowPos() API, but we think this is not good quality solution.

Krustys Donuts Jul 31, 2008 - 1:06 PM

Dear Support,

Your suggestion to use CExtLabel::SetBitmapEx() works great. The only issue is that if there is a CExtButton beneath the CExtLabel control, the button control is not visible. Only when I mouse over the button does it become visible. This behavior is seen when the tabbing order of the CExtLabel control is greater than that of the CExtButton control.



Technical Support Aug 1, 2008 - 3:12 AM

If you are using resizable dialogs with anchored controls, then the dialog windows should have the WS_CLIPCHILDREN style for flicker free resizing. This style does not allow dialog controls to intersect with each other and be transparent. Besides, we have no idea when and why in the real life the static label control should be above the clickable input controls such as buttons.

Technical Support Jul 30, 2008 - 4:35 AM

We just sent you the test project which loads PNG file (that was sent us by Gil) successfully.

In addition to comments by Jeremy in this thread we must say the following: there is no difference between the CExtBitmap, CExtBitmapCache and CExtSkinBitmap classes in terms of how they paint bitmaps with alpha-channel. The CExtBitmap class is a base class and it contains 100% of features required for painting any bitmaps. Its key feature is that it’s handle-less. I.e. it does not eat even one GDI handle in comparison with MFC’s CBitmap class. The CExtBitmapCache class eats one GDI’s HBITMAP handle what allows it to paint a bitmap a bit faster, but this is true when running on Windows 2000 or later Windows OS. The CExtSkinBitmap class from the ProfSkin library simply contains methods for PNG format loading. All the classes can draw the same bitmap formats absolutely equally. If the loaded image format is not based on alpha channel, then the CExtBitmap::AlphaBlend() methods simply invoke appropriate CExtBitmap::Draw() methods. But all the CExtBitmap::AlphaBlend() methods work equally to each other and the same is true of all the CExtBitmap::Draw() methods. The overloaded method versions are provided for convenience only. Besides, although Windows OS supports alpha channel bitmap painting only starting from Windows 2000, you can use the CExtBitmap::AlphaBlend() methods in any Windows OS versions starting from Windows 95.

The PNG loading and using in Prof-UIS is exactly the same simple and trivial task as BMP file usage in MFC, We believe the problem is still hidden in something what we haven’t yet discussed If you need a remote desktop connection for fixing this problem, then please let us know.

Jeremy Richards Jul 29, 2008 - 3:49 PM

One other thing.  While I have been able to get the CExtSkinBitmap’s PNG support to work and found it adequate for loading and displaying PNGs, if you are going to do anything more sophisticated than just that, you might consider moving to a more extensive image manipulation library, such as CxImage which is free.  CxImage is free and offers a much broader range of support as well as it is a little easier (IMO) to work with.  Of course CxImage doesn’t give you all the UI elements that Prof-UIS does, so I tend to use both in my projects.

Jeremy Richards Jul 29, 2008 - 3:45 PM

This one took me a while.  It appears that not all of the various overrides of that function properly work in a CExtSkinBitmap.   I don’t know why, as it seems like it would have been easy to implement.  I wanted to use the 2 parameter one at first as well.

I finally had to use this one:   

virtual int AlphaBlend( HDC hDC, int nDstX, int nDstY, int nDstWidth, int nDstHeight, int nSrcX, int nSrcY, int nSrcWidth, int nSrcHeight, BYTE nSCA = 0xFF ) const;

Note:  Since CExtBitmapCache implements an AlphaBlend as well, you have to actually manually call the one from CExtBitmap like this

lockBkgnd->CExtBitmap::AlphaBlend(*dc,,,,, 0, 0,,, 0x70);

Hope this helps