I am trying to create a custom control that displays a bitmap with per-pixel alphablend (as some of you already know for other questions).
Right now I am using a custom control in the resource editor and I attach it to a class derived from CWnd. When I register my custom class I set the hbrBackground of the WNDCLASS structe to NULL_BRUSH to achive the transparency of the control.
In the OnPaint of the control I use AlphaBlend to paint the per-pixel alpha blend bitmap.
This works quite well but I have this two problems:
I want to change the displayed bitmap when the mouse is over the control. As the control is transparent, the areas that one bitmap that are not overlapped by the other bitmap are not erased. How can I erase the background when the image is changed?
The second problem is related with two overlapping controls. My control is painted over other control that has a gradient (in fact is inside other control). The problem is that if I put my control before in the z-order the other controls overlap my control and mine is not displayed. If I put the other control before in the z-order I can not get the mouse message in my control.
Maybe I am doing something wrong or I am wrong in how I am trying to implement my control. Any kind of help would be appreciated.
Thanks,
Javier
I'll take a chance. :-)
This should give you all you need to accomplish what I think you want.
General Solution for Transparent Controls
As far as Z-order issues, the z-order does not affect message priority. You'll need to post some code so we can determine what is happening there.
Related
Since there is no way to deep customizing (a gradient background for example) win32 controls (such as buttons, menu items e.t.c) many people advise to create an own custom control.
And if I need a custom button I will use WM_MOUSEMOVE, WM_LBUTTONDOWN and a shadow buffer. I will draw all controls on the shadow buffer and then use BitBlt(hDC, ...) for my window.
But if I want to create a custom menu I must to foresee that menu can be drawn outside of the client area.
At first I need to mouse tracking outside of the client area. SetCapture(hWnd) seems to be a bad solution as it blocks mouse tracking for windows below.
Then I need to draw/erase items outside of my window. Erasing with InvalidateRect(NULL, NULL, TRUE/FALSE) seems to be a bad solution too as it cause of blinking.
What is the best approach to create custom menu with WinAPI?
Runtime menus that can appear anywhere on the screen can be shown with TrackPopupMenu() function. Create the menu with CreateMenu(), AppendMenu() etc, then show it with TrackPopupMenu().
I have a popup dialog( CDialog ) that handles WM_CTLCOLOR message to color itself. It is having some controls (like bitmap buttons) that draws themselves using OwnerDraw. It is also having a control that displays an image with size that takes up to 70% of the dialog.
When user re-sizes the dialog, some of the controls in the dialog should be re-positioned (not re-sized). It also involves re-sizing of the image inside the dialog. As the re-sizing of image makes the whole process slow, individual re-positioning of the controls are causing a visual effect of flickering.
I need to get rid of these. One idea is to put the controls as the children of an intermediate dialog that is the child of the original popup dialog. So, when there is a re-size, I can re-position the dialog only instead of moving each controls individually. (Re-position happens only in one direction (x or y), so moving the intermediate dialog should be enough.
As it involves some coding effort, before going this way, I need answers to the following questions:
Will this work?
If yes, whats the complexity involved in this method?
Is there a better way?
Please help!
Simple fixes are:
creating the slow window last so that it doesn't hold up drawing of the simple controls
turning on the WS_EX_COMPOSITED style flag so Windows double-buffers the entire window, including its children. Beware of painting artifacts
turning off the WS_CLIPCHILDREN style flag so the holes are not so noticeable. Making the background white would accomplish the same
keeping the drawing of slow controls simple between WM_ENTERSIZEMOVE and WM_EXITSIZEMOVE
using less controls, burning up an expensive window on a simple string or image is unnecessary
It will probably work, but you should try solutions that don't alter your control hierarchy before, because it has other subtle consequences (focus, tab order, message notifications, etc).
Try one or all of the following:
Use BeginDeferWindowPos/DeferWindowPos/EndDeferWindowPos functions to move the children.
Set the WS_CLIPCHILDREN style flag in the dialog.
Set the WS_EX_LAYERED extended style flag in the dialog.
I have a CDHTMLDialog in a BHO that I want to be partially transparent, in the sense that the transparent area changes according to the logic of the dialog. I got it to become transparent visually (using SetLayeredWindowAttributes), but it is critical to make this region truly transparent, because otherwise when I click on the transparent region my clicks do not reach the IE window which is below the transparent part of my dialog. I temporarily fix this by constantly resizing my dialog according to the size of the active part of the dialog, but I can't keep up with this forever...
I think the solution has something to do with what windows calls "regions" (http://msdn.microsoft.com/en-us/library/dd162915%28VS.85%29.aspx) but I'm not exactly sure how to work with them. Can anyone point me in the right direction?
I don't think you want to make parts of your window transparent, what you want to do is (I think) set the window region (like you mention). Read the MSDN on SetWindowRgn() - basically you define a GDI object of type HRGN (if you're using MFC, CRgn) which described a surface of a certain shape, and eventually with parts cut out. Windows then considers only the 'region' that you set on a window as the part of the window to use. Basically it's how you make non-rectangular windows. A 'region' isn't a 'transparent' part of a window, it's a way to discard areas of a window, in a way.
I found the way to make an entire window transparent and click-through here:
http://www.codeproject.com/KB/wtl/transparent.aspx
But it's not useful for my case where I only want the transparent part of my window (transparent by HTML/CSS definitions) to be click-through...
Update: Apparently, the clicks are supposed to go through the transparent parts (see http://jalaj.net/2007/02/05/form-with-a-hole/), but in my CDHTMLDialog they don't. My best guess is that a sub-window of the BHO catches my clicks, but I don't really think that makes much sense...
I have tried several methods, but problems always exist. Sometimes the sub-window didn't refresh and sometimes the sub-window will keep blink.
This is a sample project that i have written
http://rapidshare.com/files/283950611/TestProject.7z.html
My method to implement that is:
Put a scroll bar on the top of sub-window, whenever the scroll bar was dragged, the sub-window would be moved as well.
And every dialog is inherited from CDialogBase, All the drawing is done in this class, Drawer.h is a helper for drawing.
Only when the DC that user assigned is dirty, then system will redraw the window, it is used for accelerating the painting.
WS_EX_LAYERED only can be added to with top level window, not sub-window; I've tried to modify the window style from WS_CHILD to WS_OVERLAPPED, and then using layed window, and then clip the visiable area of the window, but, the result is not what I expected.
Anywhere, thank you for your advice...
Have you considered using WS_EX_LAYERED and then using UpdateLayeredWindow. It can get quite complicated but allows for things like per-pixel alpha and eliminates flicker like you are seeing.
Look here:
http://www.nuonsoft.com/blog/2009/05/27/how-to-use-updatelayeredwindow/
for more info.
Normally, the thickness of a window is 4 pixels, which can be retrieved by GetSystemMetrics method. Can I change its value, for example 2 pixels?
Thank you very much!
Simple answer: No. Not for a specific window.
Complicated answer: The border is drawn as part of the "non-client" region of the window. This is all handled (under the hood) by the default processing (i.e. DefWindowProc), along with the caption, minimize, maximize buttons, etc. You can override this by handling the WM_NCPAINT message. You'll then be responsible for drawing the entire non-client area of your window. You'll also want to handle the WM_NCCALCSIZE message, so that Windows knows how much of the remaining space to give to your client area.
Alternatively, you can set the border style of your window to none. This will allow Windows to draw the caption for you, although it'll probably look slightly different. Unfortunately, by doing this, you lose the drag-to-resize functionality. For that, you'll need to handle the WM_NCHITTEST message.