using bitmap for dialog background
tru-random
background for a dialog-based program. I found this code in another post
searching thru this newsgroup. And thought that this approach could be
applied, instead of using EraseBkgnd message handler.
HBRUSH CBitmapBkgdTestDlg::OnCtlColor(CDC* pDC, CWnd* pWnd, UINT nCtlColor)
{
hbr = CDialog::OnCtlColor(pDC, pWnd, nCtlColor);
if(nCtlColor == CTLCOLOR_DLG)
{
HBITMAP hBmp = LoadBitmap(AfxGetResourceHandle(),
MAKEINTRESOURCE(IDB_BITMAP1));
hbr = CreatePatternBrush(hBmp);
}
return hbr;
}
Joseph M. Newcomer
eventually fill up all of the GDI resources with duplicate pattern brushes. Create the
brush one, in the class, most typically during the constructor. Create it as a CBitmap
object so when the dialog exits, the brush will be reclaimed.
joe
Joseph M. Newcomer [MVP]
email: newc...@flounder.com
Web: http://www.flounder.com
MVP Tips: http://www.flounder.com/mvp_tips.htm
tru-random
handler. However, I was trying to use the "OnCtlColor" message handler to
make the dialog background black, before I placed the bitmap as the dialog
background. And now I have found that the bitmap displays well, but there is
no black background. And the dialog will repaint anything that is underneath
it. So, how could I make a black background before I also place a smaller
bitmap background onto this black background???
I've also considered stretching the bitmap background for the dialog, but
I am not sure if there are any consistency problems with other monitors and
computers. Since there will be controls placed in certain positions on this
bitmap background.
This is the code I am using. And the class declarations and the
OnInitDialog() code is first.
class CBitmapBkgdTestDlg : public CDialog //header file
{
"all the other code is here"
private:
CBrush brBrush;
UINT resCrd;
}
-------------------------------------------------
BOOL CBitmapBkgdTestDlg::OnInitDialog()
{
"all the other code is here"
// TODO: Add extra initialization here
brBrush.CreateSolidBrush(RGB(0,0,0));
resCrd = IDB_BACKGROUND;
}
-----------------------------------------------
HBRUSH CBitmapBkgdTestDlg::OnCtlColor(CDC* pDC, CWnd* pWnd, UINT nCtlColor)
{
return brBrush;
}
BOOL CBitmapBkgdTestDlg::OnEraseBkgnd(CDC* pDC)
{
if(resCrd == 0)
return CDialog::OnEraseBkgnd(pDC);
int Xpos(0);
int Ypos(0);
int x(0);
int y(0);
CBitmap bmp;
BITMAP BmpInfo;
CDC dcMem;
CBitmap *pOldBmp;
bmp.LoadBitmap(resCrd);
bmp.GetBitmap(&BmpInfo);
int bmpw = BmpInfo.bmWidth;
int bmph = BmpInfo.bmHeight;
dcMem.CreateCompatibleDC(pDC);
pOldBmp = dcMem.SelectObject(&bmp);
CRect rect;
GetClientRect(&rect);
if(bmpw < rect.Width())
x = (rect.Width() - bmpw)/2;
else
x=0;
if(bmph < rect.Height())
y = (rect.Height()-bmph)/2;
else
y=0;
pDC->BitBlt(x, y, rect.Width(),
rect.Height(), &dcMem, 0, 0, SRCCOPY);
dcMem.SelectObject(pOldBmp);
dcMem.DeleteDC();
bmp.DeleteObject();
return true;
}
Joseph M. Newcomer
On Sat, 10 Feb 2007 21:16:28 GMT, "tru-random" <remov...@tru-randomsoftware.com> wrote:
> I thought that I should go ahead and use the "OnEraseBkgnd" message
>handler. However, I was trying to use the "OnCtlColor" message handler to
>make the dialog background black, before I placed the bitmap as the dialog
>background. And now I have found that the bitmap displays well, but there is
>no black background. And the dialog will repaint anything that is underneath
>it. So, how could I make a black background before I also place a smaller
>bitmap background onto this black background???
> I've also considered stretching the bitmap background for the dialog, but
>I am not sure if there are any consistency problems with other monitors and
>computers. Since there will be controls placed in certain positions on this
>bitmap background.
*****
Once, a long time ago, I was given such a project. The dialog background was beautiful
pastel colors, and the controls were placed at exact x,y coordinates. It worked fine at
640x480x256. Unfortunately, the customers were now buying 800x600 laptops and wanted
full-screen display. The result was a total disaster. The solution was to remove the
pretty colors, since they actually added nothing to the value of the product, put controls
where they should go, and handled resizing properly. The difference was that the pretty
colors were gone, and the product worked at any resolution, on any display, at any color
depth, with any font size. The notion that you can take a bitmap and use it as a guide
for layout is pretty risky under almost any imaginable modern condition, where there are
multiple resolutions, multiple display sizes, etc., and in fact any one system can have
two or more resolutions (e.g., my main monitor runs 1900x1200 and my secondary monitor
runs 1024x768, so the resolution for full-screen depends on which monitor I've maximized
it). You can safely assume that resizing the bitmap image will fail to give desired
results. Trying to correlate controls with bitmap positions is going to be
difficult-to-impossible. It is one thing to just draw a background; to draw something
that has "holes" in it for controls is a nightmare. You cannot control the size of the
controls; if you try, you defeat the automatic scaling done for dialogs, and in some cases
make localization near-impossible.
*****
>
>This is the code I am using. And the class declarations and the
>OnInitDialog() code is first.
>
>class CBitmapBkgdTestDlg : public CDialog //header file
>{
> "all the other code is here"
> private:
> CBrush brBrush;
> UINT resCrd;
>}
>-------------------------------------------------
>
>BOOL CBitmapBkgdTestDlg::OnInitDialog()
>{
> "all the other code is here"
>
> // TODO: Add extra initialization here
> brBrush.CreateSolidBrush(RGB(0,0,0));
> resCrd = IDB_BACKGROUND;
>}
>-----------------------------------------------
>
>HBRUSH CBitmapBkgdTestDlg::OnCtlColor(CDC* pDC, CWnd* pWnd, UINT nCtlColor)
>{
> return brBrush;
>}
*****
This will certainly cause an area to be painted black. The problem is that given you are
using OnEraseBkgnd, this may be either redundant or meaningless. Or perhaps erroneous.
****
What you should do here is FillSolidRect the bitmap, which should be the size of the
dialog, with a black image. Then in the line below, you'll BitBlt the image into that
black bitmap.
*****
> pDC->BitBlt(x, y, rect.Width(),
> rect.Height(), &dcMem, 0, 0, SRCCOPY);
>
> dcMem.SelectObject(pOldBmp);
> dcMem.DeleteDC();
> bmp.DeleteObject();
>
> return true;
>}
>
David Ching
news:fq5ts21r1b7o3kh2i...@4ax.com...
Dialogs with resizeable controls are OK if pretty interfaces are not a
premium, but they suck if it is at a premium. Not everyone agrees with your
tradeoffs that functionality (i.e. perserving user's choice of font size) is
more important than using a fixed size window. I happen to agree with you,
but that severely limits what the graphic artist can do. I've had several
contracts that called for a fixed window about 750x550 (to fit on a 800x600
screen), and for a fixed size font that fit within the gaps provided in the
background bitmap.
-- David (MVP)
Joseph M. Newcomer
*****
The major problem is one of whether one fights the basic paradigms of the system or flows
with them. I've used a lot of different systems in my career, and I've learned that
attempts to fight the paradigms results in increased development costs, increased
maintenance costs, and overall issues about portability including from relelease to
release of the operating system. After many years of fighting systems, I finally have
realized that it is always a losing proposition, so I tend now to say "what is the purpose
of this product?" and fit it into the paradigms, rather than say "the cosmetics are more
important than the functionality, so first and foremost it has to look cool, and only then
do we worry about whether or not it works". The contract I described was about 12 years
ago, and since then I've had several contracts where the major selling effort was to
convince the client that "looks cool" and "works robustly under conditions you cannot
predict or control" are frequently opposing goals, and that the customers are going to be
a lot happier with the latter than the former. I've won every time, and delivered robust
products that work under all kinds of conditions.
It is also worth pointing out that the "cool" pastel bitmaps that looked so nice on a VGA
in the office (with 256 colors) failed completely on the early laptops, which often only
had 16 colors. They got a lot of complaints about that, too. At least today color depth
is no longer an issue. But everything else is.
One colleague worked on one where he had to stretchblt to fit everything into whatever
resolution there was. He then had to scan the bitmap looking for "holes" of a specific
color (think: video bluescreen model), and when he found a "hole" in the approximately
right place he'd compute the extent of the hole by doing pixel analysis, and size the
control to fit. Worked perfectly until they got a German customer who wanted German words
for all the pushbuttons, etc.
Sometimes educating the customer is one of the important roles of a developer.
joe
*****
>
>-- David (MVP)
David Ching
> One colleague worked on one where he had to stretchblt to fit everything
> into whatever
> resolution there was. He then had to scan the bitmap looking for "holes"
> of a specific
> color (think: video bluescreen model), and when he found a "hole" in the
> approximately
> right place he'd compute the extent of the hole by doing pixel analysis,
> and size the
> control to fit. Worked perfectly until they got a German customer who
> wanted German words
> for all the pushbuttons, etc.
>
Yeah StretchBlt() would work very poorly here. But I'm talking about using
a fixed-size bitmap for the background and retaining that size, no
stretching, regardless of the resolution.
> Sometimes educating the customer is one of the important roles of a
> developer.
Have you bought a wireless PC-Card Network adapter lately? Most of the big
name ones come with the manufacturer's idea of a "skinned" control panel
that looks great and is a fixed size. I contract for companies that believe
skins aid the customer in setting up their wireless network and are willing
to pay for slick looking apps (that are really less functional due to their
inability to resize). I sincerely doubt they need to hear it from me that
making a standard looking Windows dialog is to their benefit, which BTW,
given the finicky nature of consumer software, I don't really believe.
-- David (MVP)
Joseph M. Newcomer
On Mon, 12 Feb 2007 05:00:20 GMT, "David Ching" <d...@remove-this.dcsoft.com> wrote:
>"Joseph M. Newcomer" <newc...@flounder.com> wrote in message
>news:o3lus25v1uhuc9cjb...@4ax.com...
>> One colleague worked on one where he had to stretchblt to fit everything
>> into whatever
>> resolution there was. He then had to scan the bitmap looking for "holes"
>> of a specific
>> color (think: video bluescreen model), and when he found a "hole" in the
>> approximately
>> right place he'd compute the extent of the hole by doing pixel analysis,
>> and size the
>> control to fit. Worked perfectly until they got a German customer who
>> wanted German words
>> for all the pushbuttons, etc.
>>
>
>Yeah StretchBlt() would work very poorly here. But I'm talking about using
>a fixed-size bitmap for the background and retaining that size, no
>stretching, regardless of the resolution.
****
Which works fine until you have to fit it into a requirement that says "the application
must fill the full screen". The problem I faced, and my colleague faced, was the
constaint that the model was always full-screen. When he investigated, he found that it
would take enough bitmaps to handle all screen resolutions and all font sizes, and this
was unrealistic. Key here also is that at any given time in history, the enumeration of
all known resolutions does not predict future resolutions. It also doesn't handle the
case of two different resolutions co-existing on the same machine (in the era he did this,
multiple monitor support didn't exist). An 800x600 image isn't going to work on a
1900x1200 monitor if you want the ability to maximize.
****
>
>
>> Sometimes educating the customer is one of the important roles of a
>> developer.
>
>Have you bought a wireless PC-Card Network adapter lately? Most of the big
>name ones come with the manufacturer's idea of a "skinned" control panel
>that looks great and is a fixed size. I contract for companies that believe
>skins aid the customer in setting up their wireless network and are willing
>to pay for slick looking apps (that are really less functional due to their
>inability to resize). I sincerely doubt they need to hear it from me that
>making a standard looking Windows dialog is to their benefit, which BTW,
>given the finicky nature of consumer software, I don't really believe.
****
I have yet to use a skinned app that looked like an improvement.
By the way, the bitmap I was using had no functional value; it just had cute pastel areas
that grouped controls, instead of using group boxes, and a "watermark" that was the
company logo. I was able to preserve the logic of the colors just by placing static image
boxes on the dialog and painting them the same colors as in the bitmap, but they all
adjusted properly to font size changes and resolution changes. I used labels in static
controls instead of text drawn on the bitmap (which would not have localized easily).