I am showing thumbnails (in a WTL/ATL/C++ application) using IShellItemImageFactory. Everything works fine all the way up to windows 8. There, some icons come with some black lines where transparency should be. It is slight but visible: http://i59.tinypic.com/ru2vmf.png
It happens to a minority of icons only.
After extracting the bitmap I show it (exactly as returned by GetImage(SIIGBF_RESIZETOFIT)) in a standard static control with STM_SETIMAGE. The glitch is still there if I add the bitmap in an imagelist
what can be the problem?
Related
I made an MFC app for my friend using VS2015 in Win10. It looks like this, which is exactly the same as in resource editor.
.
But when he ran the app on his computer in Win7, the Bitmap image in Picture Control enlarges and covers up some text boxes below, which looks like this.
.
After I searched and realized it may be related with DPI awareness. I disabled DPI-Awareness in property page of Manifest Tool and rebuilt. The same thing happened even when it runs in Win10.
Could someone help me explain the cause of this and find a solution to fix the size of the image control? Thanks.
The main problem is that a dialog from a resource is always measured in DLUs.
And DLUs are calculated from the size of the font, that is used for the dialog.
See this article how dialog base units are calculated.
Now you have a static picture control that is sized in DLUs. The bitmap is just scaled in pixels and is never resized, when you assign it to a static dialog control. And because the real size of the static control depends on the used font, you get different layouts for your dialog and your bitmap.
And because just the font changes when you choose no DPI awareness and because the font changes from windows version to windows version your dialog always look different.
Advice: Paint you picture your own and stretch it accordingly.
Also this stackoverflow question is nice documents and shows the effect of DLUs.
And here some code for auto sizeing picture controls.
An auto-sizing bitmap picture control
A simple image preview class using GDI+
CxImage
Normally, I prefer to keep control in my hand by using SetWindowPos() to set the size of image I want in different situations. You can use below two lines to control/set position and size of your image.
Assume ID of the Picture Control is IDC_STATIC2 then you can use like:
CStatic * pStatic = (CStatic *) GetDlgItem(IDC_STATIC2);
pStatic->SetWindowPos(NULL,20,20,50,50,0);
I built simple c++ Windows Form project with Visual Studio 2015.
My application has toast (Windows 10), and that shows icon like this.
Application icon has transparent background.
How can I remove blue background of icon?
Source Code: https://github.com/chaeyk/SoundDeviceToggle
Apologies, A bit late BUT ... in my effort to try and help😏
... Did you try both a transparent pixel PNG?png here
... and/or a transparent pixel GIF?gif here
( see 2 attached 1x1px images )
NOTE: I'm not sure what filetype you may need, but the same instance applies. If anyone wants me to supply a transparent image of a certain type eg. png, ico etc let me know.👍
Else, you can easily generate transparent PNG's ...
https://png-pixel.com/
and
https://onlinegiftools.com/create-1x1-pixel-gif
I, or rather one of my users, has a very weird issue with alpha-blended icons that don't show correctly on his Windows XP installation. Usually alpha-blended icons shouldn't be a problem on XP and newer, but this one is really puzzling me.
I have an MFC CToolBar, so pretty much a normal WinAPI toolbar, and I'm feeding it with a CImageList (so basically a normal WinAPI image list). There is fallback code for screen modes < 32-bit or older operating systems, which reads my bitmap with 8-bit transparency and reduces it to pre-multiplied 1-bit transparency. On XP, with 32-bit bit depth (confirmed by the user that he uses these settings, and the icons actually show up correctly with 16-bit bit depth because of the fallback code), I create the image list with the ILC_COLOR32 flag, as indicated in the MSDN. Furthermore, the bitmap that's fed into the image list is created with CreateCompatibleBitmap (bitcount = 32, planes = 1).
On all systems I have personally tested so far, this work as intended, i.e. I get nice alpha-blended 32-bit icons on my toolbar. However, on the user's XP installation, it looks like this: http://bugs.openmpt.org/file_download.php?file_id=102&type=bug
This is what the icons look like if the alpha channel is completely ignored (you can tell by some error pixels that are normally invisible because the alpha channel is fully transparent). So despite being on XP, and despite using 32-bit screen mode, and despite using ILC_COLOR32, the alpha channel is ignored completely.
I have never seen such behaviour before, and apparently the user doesn't experience this problem with other applications. Is there anything I missed that I have to keep in mind when using alpha-blended images on toolbars on WinXP?
The relevant code for creating the image list images can be found here (code for 32-bit screen mode is at the bottom) and there (specifically PNG::Bitmap::ToDIB).
I haven't done this in a while, but I believe you need to create a 32-bpp DIBSECTION rather than a compatible bitmap to pass into the toolbar, otherwise the alpha channel can be lost--even on a system with a 32-bpp display.
I have an windows app which contains some dialogs. the dialogs have been built using mfc. I am drawing some images (.png) on every dialog using CImage::Draw() method. I want to mention that I am not using any picture contol on the dialog to render these images instead I am loading them at runtime using some handle.till this everything is ok. now when the image is loaded the background of those images are coming as white. the images in the resource file does not have the white background. my question is how to change the background of these images while drawing them on the dialog? I want the background of the image similar to the color of default dialog which i am using.
One more question the .png images are not rendering well(the images are scattered) in the dialogs of windows server 2008 R2 machine. what could be the possible remedy for this?
any help will be appreciated.
Your PNG images are obviously not 32-bit. You need an alpha channel and a transparent background. Open your images in e.g. Paint.NET. I bet your background is white there too! Regarding the image quality, are you stretching your images on draw?
Edit: For 8-bit imagers, I believe a call to SetTransparentColor is required. For 32-bit images, perhaps this function will do: TransparentBlt
In our MDI application - which is written in MFC - we have a function to save a screenshot of the MDI client area to file. We are currently doing a BitBlt from the screen into a bitmap, which is then saved. The problem is that some of the MDI child windows have their content rendered by OpenGL, and in the destination bitmap these areas show up as blank or garbled.
I have considered some alternatives:
- Extract the OpenGL content directly (using glReadPixels), and draw this to the relevant portions of the screen bitmap.
- Simulate an ALT+PrtScr, since doing this manually seems to get the content just fine. This will trash the clipboard content, though.
- Try working with the DWM. Appart from Vista and Win7, this also needs to work on Win2000 and XP, so this probably isn't the way to go.
Any input will be appreciated!
The best way to get a bitmap from an OpenGL window is to draw the content to a bitmap 'window'. See PFD_DRAW_TO_BITMAP for more information on how to do this.
If you want to go with the Alt+PrtScr way, you have to consider that many users have their own print screen tool installed which reacts on that very same hotkey. So you can't be sure that this hotkey will copy the content to the clipboard. It may just open the window of the installed print screen tool/utility.
Use the glReadPixels() approach. This question is asked quite often, here, on the gamedev.net forums and on other places, so google should show you code samples easily, but the glReadPixels() approach is the generally recommended approach.
Simulating keypresses is a recipe for disaster, I would stay away from that.