|
OK, I get it,I mad the WM_ERASEBKGND return 1, doesn't seem to matter yet what I set it to, and fixed the code I posted. I messed it up from trial and error, and left off at error.
This is the correct code
bmp_BGInstallation = LoadBitmap(hIIS_Instance, MAKEINTRESOURCE(IDB_BG_INSTALL_PANE_BMP));
mem_DCInstallation = CreateCompatibleDC(hdc);
SelectObject(mem_DCInstallation, bmp_BGInstallation);
BitBlt(hdc, 0, 0, 504, 331, mem_DCInstallation, 0, 0, SRCCOPY);
DeleteDC(mem_DCInstallation);
DeleteObject(bmp_BGInstallation);
Thanks for pointing out the WM event, I remember reading it somewhere earlier, but forgot about it.
Say, 1 more question, if I create a larger bitmap of the same image, would windows automatically size it down, so I can resize the window larger, without losing image quality?
|
|
|
|
|
jkirkerx wrote: if I create a larger bitmap
In that case you would probably need to use StretchBlt()[^].
|
|
|
|
|
It took me awhile to understand the process, but as a by product, I learned how to create regions in the window, and paint them, and they work in the resize event as well.
I'll try the above suggestion first, before trying the below dll integration.
Thanks for the help, the information is out there, but I'm not using the right words to find it.
|
|
|
|
|
jkirkerx wrote: the information is out there, but I'm not using the right words to find it.
Sure, this is a fairly obscure part of Windows programming, most people just use the default background. But, it sounds like you are getting there.
|
|
|
|
|
I got it!, just finished. I doubled the size of the artwork, and just used a PNG file, and it loaded. Messed around with the numbers, and mode, came out great!.
I also made my Textout dynamic as well, but I ran into an math warning, I tried (double).38, but still got the error.
Anyways, Thanks for the pointers, I get this feeling that what I'm doing is old school, and that folks moved on to MFC or something.
warning C4244: 'argument' : conversion from 'double' to 'int', possible loss of data
TextOut(hdc, clientRect.right * .38, clientRect.bottom * .03,
L"IIS Webserver Installation",
_tcslen(L"IIS Webserver Installation")
);
// My new Code
GetClientRect(cWnd, &clientRect);
hRegion1 = CreateRectRgn(clientRect.left, clientRect.top, clientRect.right, clientRect.bottom - 57);
hBGBrush1 = CreateSolidBrush(RGB( 255, 255, 255 ));
FillRgn(hdc, hRegion1, hBGBrush1);
hRegion2 = CreateRectRgn(clientRect.left, clientRect.bottom - 57, clientRect.right, clientRect.bottom);
hBGBrush2 = CreateSolidBrush(RGB( 25, 25, 25 ));
FillRgn(hdc, hRegion2, hBGBrush2);
bmp_BGInstallation = LoadBitmap(hIIS_Instance, MAKEINTRESOURCE(IDB_BG_INSTALL_PANE_PNG));
mem_DCInstallation = CreateCompatibleDC(hdc);
SelectObject(mem_DCInstallation, bmp_BGInstallation);
SetStretchBltMode(hdc, COLORONCOLOR);
StretchBlt(hdc, 0, 0, clientRect.right, clientRect.bottom - 57, mem_DCInstallation, 0, 0, 1008, 612, SRCCOPY);
DeleteDC(mem_DCInstallation);
DeleteObject(bmp_BGInstallation);
|
|
|
|
|
TextOut(hdc, clientRect.right * .38, clientRect.bottom * .03,
The warning(s) come because you are calculating a double (i.e. floating point) value (.right * .38) and then using it in a place where an integer is required, so the automatic conversion to integer may lose some precision. You may wish to modify your code to use integer values only; see the documentation for TextOut()[^].
|
|
|
|
|
You may have a look at my DLL[^] if you need to resize the image without loosing too much quality.
If the Lord God Almighty had consulted me before embarking upon the Creation, I would have recommended something simpler.
-- Alfonso the Wise, 13th Century King of Castile.
This is going on my arrogant assumptions. You may have a superb reason why I'm completely wrong.
-- Iain Clarke
[My articles]
|
|
|
|
|
That DLL will come in handy in phase 2 of my project, I'm bookmarking so I can find it at the end of the month.
Thanks for looking at my post!
jkirkerx
|
|
|
|
|
Hey folks!
I am trying to find out if a DC supports AlphaBlend or not. I used GetDeviceCaps[^] with SHADEBLENDCAPS and checked for the SB_CONST_ALPHA flag, however, it seems like it happens that the DC doesn't return this flag BUT AlphaBlend[^] still succeeds on it (and produces the expected result). Am i using GetDeviceCaps the wrong way? Is this not the way to check for the support? Is GetDeviceCaps simply not reliable?
Thanks for any answers in advance.
> The problem with computers is that they do what you tell them to do and not what you want them to do. <
> If it doesn't matter, it's antimatter.<
|
|
|
|
|
How did you test for this - as a value or bit mask?
|
|
|
|
|
Bit mask:
bool DCCanBlend = ((dc.GetDeviceCaps(SHADEBLENDCAPS) & SB_CONST_ALPHA)?true:false);
> The problem with computers is that they do what you tell them to do and not what you want them to do. <
> If it doesn't matter, it's antimatter.<
|
|
|
|
|
Check the remarks section here[^].
|
|
|
|
|
Thanks for your reply. As i also said to Randor, my DCs are for printers, but to avoid vasting ink and paper i am -at least initially- working with virtual printers which print to a file like PDF. Can be that these work as screen DCs and not printer DCs, i will check into that (using GetDeviceCaps and TECHNOLOGY) and "report back".
> The problem with computers is that they do what you tell them to do and not what you want them to do. <
> If it doesn't matter, it's antimatter.<
|
|
|
|
|
They all report DT_RASPRINTER.
> The problem with computers is that they do what you tell them to do and not what you want them to do. <
> If it doesn't matter, it's antimatter.<
|
|
|
|
|
Hey Code-o-mat,
As Richard pointed out display device contexts always support alpha blending! If the return value is SB_CONST_ALPHA then it means the alpha blending will be performed using hardware acceleration. In fact I don't think Microsoft will ever add hardware acceleration to GDI. With Windows8 Metro they are moving towards Direct2D[^] 
Best Wishes,
-David Delaune
|
|
|
|
|
Thanks for the reply. I read that but my DC!s are (sometimes) for printers. However, to save on paper/ink money i am using a few "virtual" printers (like Cute PDF Writer) to print to files. Maybe these virtual drivers! DC will "function" as a screen DC rather than a printer DC when drawing onto, i will check that (with GetDeviceCaps + TECHNOLOGY) and report back what i have found.
> The problem with computers is that they do what you tell them to do and not what you want them to do. <
> If it doesn't matter, it's antimatter.<
|
|
|
|
|
Hey Code-o-mat,
Sorry about the late reply... I was out of the office today. One thing that I have learned over the years is that printer drivers often report incorrect capabilities. Generally there is not much that can be done about these edge cases. I've had similar experiences to yours when dealing with virtual device drivers.
Best Wishes,
-David Delaune
|
|
|
|
|
So i did some testing and all the virtual printer drivers say they are DT_RASPRINTER. None of them report to support AlphaBlend but by forcing them to use AlphaBlend anyways some of them succeed.
Another question came up, if a printer device reports blit support (RASTERCAPS -> RC_BITBLT), does that mean you can also blit from the device or only that you can blit to it?
> The problem with computers is that they do what you tell them to do and not what you want them to do. <
> If it doesn't matter, it's antimatter.<
|
|
|
|
|
Code-o-mat,
The author of the printer driver reports the device capabilities. And because everyone's cousin and grandma is a software engineer these days... using software is like a box of chocolates... you never know what your gonna get.
Code-o-mat wrote: Another question came up, if a printer device reports blit support (RASTERCAPS -> RC_BITBLT), does that mean you can also blit from the device or only that you can blit to it?
Bit-block transfers are suppose to be a two-way street. When you call BitBlt on a printer device context... the win32 subsystem performs some internal magic and then end up calling the printer drivers DrvBitBlt function[^]. If the device driver does not implement DrvBitBlt... it uses the default EngBitBlt function[^] (This is what the Gdi32 BitBlt uses via SYSCALL... it forwards to win32k.sys!NtGdiEngBitBlt)
Come to think of it... this is probably why some of the virtual printer drivers you are testing support alpha blending... the driver probably does not implement DrvAlphaBlend [^]so it ends up calling the EngAlphaBlend function[^].
Maybe you should consider giving your employer or users the option of using an open-source virtual printer such as Virtual Image Printer[^]. At least you would have some consistency.
I've been through similar battles with virtual USB, virtual serial and virtual printer drivers. I am very happy that Microsoft is forcing x64 device drivers to be signed. Unfortunately user-mode printer drivers are still a crapshoot.
Best Wishes,
-David Delaune
|
|
|
|
|
Guess i will just have to live with it.  Thanks. I tried blitting from the printer device (it reported it supports it) but all i get is blackness. This complicates my life a lot...
> The problem with computers is that they do what you tell them to do and not what you want them to do. <
> If it doesn't matter, it's antimatter.<
|
|
|
|
|
actually in XP the GetDeviceCaps returns support for acceleration (3=SB_CONST_ALPHA|SB_PIXEL_ALPHA). In a remote desktop session on same computer the return value is zero. The odd thing is, in Windows 10 it also returns 0, odd because you would expect once it was supported it will stay supported.
|
|
|
|
|
Hi,
Sorry about the late reply. It's the Thanks Giving holiday here. It has also been 7 years since I wrote the above comment which appears to be completely correct.
arnoudmulder wrote: In a remote desktop session on same computer the return value is zero. The odd thing is, in Windows 10 it also returns 0, odd because you would expect once it was supported it will stay supported.
I believe that this CDC::GetDeviceCaps behavior over "Remote Desktop" is because your code is not using the physical hardware display driver. I believe over RDP you are actually using the "RDP Encoder Mirror Driver" object located at (%WinDir%\system32\drivers\rdpencdd.sys) which does not have hardware acceleration.
In other words... the return value from CDC::GetDeviceCaps is correct.
Best Wishes,
-David Delaune
|
|
|
|
|
Hi there,
I'm using VC++ 7.0 wherein I'm trying to launch an exe using CoCreateInstance.
I've the executable path, but don't want to run thru the entire process list to find out the process id.
So is there a way to get the process ID directly from an CoCreateInstance for an executable of type CLSCTX_LOCAL_SERVER?
thanks in advance.
regards,
Rajesh
|
|
|
|
|
|
The first link you provide, while interesting, has nothing to do with the question.
If your actions inspire others to dream more, learn more, do more and become more, you are a leader." - John Quincy Adams
You must accept one of two basic premises: Either we are alone in the universe, or we are not alone in the universe. And either way, the implications are staggering” - Wernher von Braun
|
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
