I am trying to use some system icons such as SIID_DOCNOASSOC and SIID_FOLDER and draw them.
I have the problem that while my code works as expected in Windows 7, on Windows 10 the retrieved images are missing their mask. I cannot figure out why (the PICONINFO.hbmMask field that I can retrieve with GetIconInfo is non-null, indicating that there is a mask, indeed).
My code is written in Xojo, which uses a dialect of VB, but that should hardly matter, as I got it working in Win 7, I'd think:
dim info as SHSTOCKICONINFO
info.cbSize = SHSTOCKICONINFO.Size
SHGetStockIconInfo (SIID_DOCNOASSOC, SHGSI_ICON, info)
dim iconHandle as Integer = info.hIcon
dim destDC as Integer = ... // intialized outside
DrawIconEx (destDC, 0, 0, iconHandle, 0, 0, 0, 0, DI_MASK)
The above code fetched the icon for a plain file and then draws its mask. While the mask is correct on Win 7, the mask is all black over the entire icon's area on Win 10.
Why would that happen?
Windows XP added support for 32-bit ARGB icons with alpha transparency. These icons still contain a black and white mask bitmap but it is often not correct, it depends on the icon editor used and how the artist drew the image! They often look like the my documents icon in this article.
Vista added support for PNG images in icons (often called "compressed" in icon editors) and contain no mask bitmap. It is not documented what GetIconInfo does to create the mask for these.
The days of playing with HICON masks are long gone, if you want to draw a icon you should let windows do it for you without extracting the parts of a HICON. ImageList_DrawEx has some blending support if you need it.
If you absolutely need a mask for some reason then you should build it yourself when the icon contains alpha transparency. Pick some sort of threshold (25, 50, whatever) and treat everything higher than that as transparent when you inspect the alpha values.
Related
I am having trouble with some of my owner drawn listboxes on High DPI monitors on Windows 10 in a dialog box. The text is chopped off at the bottom. We saw the problem on Windows 7 and were able to fix it. It is not necessarily High DPI, but when the user sets a different text scaling. I solved the problem, so I thought (!), by using a CClientDC (wrapper around GetDC()) and calling GetTextMetrics() to determine the text height. Previously, our icons had always been taller than our text so it was not a problem. With larger DPI monitors we saw some customers reporting problems when they scaled the text.
Now we are getting new reports under Windows 10. The former problem is fine under Windows 7--but Windows 7 only scales to 100, 125, and 150 percent. Windows 10 (and maybe 8? -- but no customer reports) allows user defined scaling.
So, I tracked down the problem somewhat... I knew what the font height was when I called GetTextMetrics() during WM_MEASUREITEM. I went and put some code in to debug what GetTextMetrics() was during my WM_DRAWITEM. Well, they were different--20 pixels high during WM_MEASUREITEM, and 25 pixels high during WM_DRAWITEM. Obviously, that is a problem. I want the GetTextMetrics() to have the same results in both places.
My thought was that the only real difference I could think of was that during WM_MEASUREITEM I am calling GetDC() via CClientDC constructor, and that during WM_DRAWITEM I am using an already constructed HDC (which probably was from a return of GetPaint() inside GDI32.dll or another system DLL).
I thought maybe the BeginPaint() does something like select the windows HFONT into the HDC...
So, inside my WM_MEASUREITEM after getting the DC, I select the font of the listbox into the HDC, and then I call GetTextMetrics(). Lo and behold, the numbers match now in WM_MEASUREITEM and WM_DRAWITEM.
However, I don't know if I just got lucky. It's all just guesswork at this point.
Does BeginPaint() select the window font into the DC whereas GetDC() does not? Does the default handler of WM_PAINT for an owner drawn LISTBOX or COMBOBOX do something like select the window font into the paint DC?
BOOL DpiAwareMeasureGraphItem(LPMEASUREITEMSTRUCT lpM, CWnd* pWnd)
{
int iItemHeight = INTERG_BITMAP_HEIGHT + 4;
if (pWnd)
{
CClientDC dc(pWnd);
if (dc.GetSafeHdc())
{
CFont* pOldFont = dc.SelectObject(pWnd->GetFont()); // seems to fix it on Windows 10, but is it luck?
TEXTMETRIC tm;
memset(&tm, 0, sizeof(tm));
dc.GetTextMetrics(&tm);
LONG tmHeight = tm.tmHeight + 4; //pad
iItemHeight = max(iItemHeight, tmHeight);
dc.SelectObject(pOldFont);
}
}
lpM->itemHeight = iItemHeight;
return (TRUE);
}
Neither GetDC() or BeginPaint() initialise the DC they return with anything other than the default system font. But WM_DRAWITEM is different - it gives you an already-initialised DC to draw into.
The method you stumbled across is the right one. WM_MEASUREITEM doesn't supply a DC at all, so if you need one for size calculations you're responsible for obtaining it and setting it up with the appropriate font.
I realize win32 toolbar icon questions are common here, but none are relevant to my particular problem (most concern image lists, or associating with a bitmap handle).
I am trying to associate a toolbar button with an icon resource within my application. Since I am adding it to a toolbar that already has default images using TB_ADDBITMAP (new, open, save, etc), I cannot use an image list, as the article on MSDN says here:
The TB_SETIMAGELIST message cannot be combined with TB_ADDBITMAP. It also cannot be used with toolbars created with CreateToolbarEx, which calls TB_ADDBITMAP internally. When you create a toolbar with CreateToolbarEx or use TB_ADDBITMAP to add images, the toolbar manages the image list internally. Attempting to modify it with TB_SETIMAGELIST has unpredictable consequences.
MSDN says I should be able to use a resource directly with TB_ADDBITMAP, under the TBADDBITMAP::nID field:
If hInst is NULL, set this member to the bitmap handle of the bitmap with the button images. Otherwise, set it to the resource identifier of the bitmap with the button images.
The VS2008 resource editor shows a single 16x16 icon resource with the id IDI_ARROWLEFT. (I had a screenshot, but since I do not have enough "reputation" to post images you'll have to take my word for it)
This is clearly a valid icon as the following code makes the icon appear on the titlebar of the main window:
wcex.hIconSm = LoadIcon(wcex.hInstance, MAKEINTRESOURCE(IDI_ARROWLEFT));
The problem is the resource icon is not appearing on the toolbar button within the window. Below is the sample code that is loading the resource and applying it to the toolbar button:
void populateToolbarTest()
{
int index = -1;
TBADDBITMAP tbab;
TBBUTTON tbb;
ZeroMemory(&tbab, sizeof(TBADDBITMAP));
ZeroMemory(&tbb, sizeof(TBBUTTON));
SendMessage(hWndToolbar, TB_BUTTONSTRUCTSIZE, (WPARAM) sizeof(TBBUTTON), 0);
tbab.hInst = hInst;
tbab.nID = IDI_ARROWLEFT;
// SendMessage returns 0 when testing
index = SendMessage(hWndToolbar, TB_ADDBITMAP, 1, (LPARAM)&tbab);
if (index == -1) return;
tbb.iBitmap = index;
tbb.fsState = TBSTATE_ENABLED;
tbb.fsStyle = TBSTYLE_BUTTON;
// result is set to 1 when testing
LRESULT result = SendMessage(hWndToolbar, TB_ADDBUTTONS, 1, (LPARAM)&tbb);
}
This code successfully produces a button. However, there is no icon displayed, unlike with the defaults that I used in IDB_STD_SMALL_COLOR
I finally got it working. Turns out, it had nothing to do with the code.
Microsoft is EXTREMELY picky about the EXACT format of the image being referenced. It you use TB_ADDBITMAP with a custom image, it MUST be 256 colors, it MUST have the MS-Specific index format, and the only color I've gotten to register as transparent is black. I spent an hour in Photoshop messing with different formats and colors before figuring this out.
The clue was the CreateMappedBitmap function in the example on MSDN. The page on CreateMappedBitmap had this statement:
This function is fully supported only for images with color maps; that is, images with 256 or fewer colors.
What it doesn't mention is that this is true regardless of whether you use this function or not. I have tried each scenario with and without this helper function, as well as tried every other 256-color BMP index format. Some other formats managed to show up, but they were mangled.
Theoretically, you can use the CreateMappedBitmap COLORMAP to specify a transparency color other than black, but I'm not familiar enough with the "6 level RGB" format to know how to specify an exact color.
(ref: http://en.wikipedia.org/wiki/List_of_software_palettes#6_level_RGB)
Unless you're mixing custom icons with default ones, I would recommend sticking with TB_SETIMAGELIST. From what I've read, it's much more flexible (for example, it accepts more than 256 colors.)
(ref: Win32 Toolbars and 24bit Images)
When I convert an Enhanced Metafile (constructed via GDI+ in C#) into an old-style Windows Metafile, the results are very rough, apparently because coordinates are being rounded to the nearest screen pixel. I see this if I convert either via
GetWinMetaFileBits(emfh, bits_l, bits, MM_ANISOTROPIC, GetDC(0));
or using GDI+'s Metafile::EmfToWmfBits. The culprit is presumably the screen DC being used. This posting suggests using a printer DC, which works for me, but obviously will not work if the user has no printers installed. Is there a better way? I have considered creating a high-resolution in-memory DC for the purpose, but I can find no proper documentation for doing so, and I also worry about the RAM used.
The normal way is to create a much higher resolution memory DC, render to that and then save it however you want. Note that font sizes can get screwed up by this.
HDC memDC = CreateCompatibleDC ( hDC );
HBITMAP memBM = CreateCompatibleBitmap ( hDC, nWidth, nHeight );
SelectObject ( memDC, memBM );
With nWidth , nHeight much larger.
The CreateCompatible bit should set all the dpi etc, but I have had problems where the fonts were drawn fixed pixel size rather than rescaled - so they ended up being only 10pixels high on a 10,000 pixel image
Ask Google for ENMETA.EXE
Description by Microsoft
Example in download included.
I wrote a free game a few years ago: http://www.walkover.org. For the lobby and menus, it uses normal dialogs like win32. When the actual game starts it uses OpenGL.
Now, on Windows 7, when the actual game starts, it switches windows aero glass off and switches it back on when the game is over.
Is there something I can do to prevent this from happening? Some special flags that keep the glass on if it is on? (For newer, I have been using DirectX and this doesn#t happen there.) Maybe some (new) flag I have to specify somewhere?
I'm using this pixelformatdescriptor:
static PIXELFORMATDESCRIPTOR pfd =
{
sizeof(PIXELFORMATDESCRIPTOR), // size of this pfd
1, // version number
PFD_DRAW_TO_WINDOW | // support window
PFD_SUPPORT_OPENGL | // support OpenGL
PFD_DOUBLEBUFFER, // double buffered
PFD_TYPE_RGBA, // RGBA type
32, // 24-bit color depth
0, 0, 0, 0, 0, 0, // color bits ignored
0, // no alpha buffer
0, // shift bit ignored
0, // no accumulation buffer
0, 0, 0, 0, // accum bits ignored
0, // 32-bit z-buffer
0, // no stencil buffer
0, // no auxiliary buffer
PFD_MAIN_PLANE, // main layer
0, // reserved
0, 0, 0 // layer masks ignored
};
This problem is caused by all of the following:
Windows 7
OpenGL
Creating a window that matches your screen rect exactly (Fullscreen)
Calling Swap Buffers for the second time
Old graphics card drivers
I have the same problem and I tested 2 AAA game engines that use OpenGL and can confirm they both had the same problem. DirectX seems unaffected.
This means your window create is fine, it is not a code problem.
I would recommend updating your graphics card drivers to solve the problem.
A short term work around I found was to create a window that is 1 pixel larger than your screen resolution (on either width or height)
This tricks windows into not detecting that you have gone into fullscreen and doesn't trigger the problem.
I think this can happen if you create an OpenGL rendering context that is incompatible with Aero Glass. IIRC one of the cases that can cause this is if you create a window using 16-bit colour. Aero Glass can't render in 16-bit colour, so for some technical reason, Windows has to completely disable Aero Glass (even though only your app is using it). Try using 32-bit colour.
There might be other settings that disable it for similar reasons. In short, double check all the settings you're creating OpenGL with, and think "would Aero Glass switch off if the desktop was switched to this mode?".
Not sure exactly what you're doing that's causing this, but it's probably just as well -- Microsoft's OpenGL implementation in Windows 7 is not exactly perfect, to put it nicely. In fact, in most of my OpenGL code, I've taken to explicitly turning off the DWM. Otherwise, bugs in Microsoft's implementation basically stop it from working at all. Though I can work around that some extent in other ways, the performance is so poor it renders the code essentially unusable anyway (I haven't done serious measurements, but at an immediate guess I'd say at least 5:1 performance loss).
I once encountered a problem in my application that GDI couldn't read OpenGL-rendered window contents when trying to do BitBlt from the window DC. This was back then when Vista just came out. Using PFD_SUPPORT_GDI would work around this, but it would also disable Aero. I guess this issue made a lot of old apps broken, so they forced it to be on in some cases. Not sure what's your case here. I would bet on a driver stub issue.
Just my own limited experience with OpenGL, Aero and GDI.
I need to draw a column of vertical text (in Japanese language - it is drawn top-to-bottom instead of left-to-right) in my native C++ Win32 GUI application. I've looked through MSDN and only found how to draw right-to-left text.
How do I output top-to-bottom text except drawing each character separately?
The straight Win32 API has no way to draw (unrotated) vertical text (with an arbitrary font) in that way except 1 character at at time.
You can do more complex text output with GDI+
But that probably isn't what you want either, since the text will be vertical, but the characters will also be rotated.
Similarly, you can use CreateFont with an lfEscapement value of 900 or 2700 to get rotated text, but this will rotate everything. So that doesn't help either.
To do Japanese Top to Bottom drawing, you want the characters to be unrotated, but the placment of each character to advance in Y but not in X. Windows has no API that does this for all fonts. (you can do right-to-left and left-to-right, but not top-to-bottom).
In theory creating a font with an Orientation of 900 and an escapement of 2700 would do what you want, but it appears that if you set the escapement, then the orientation is ignored for most fonts. It's possible that for Japanese fonts, this will work differently. It's worth spending some time to play with. (see the addendum for more information on this)
I think your best bet is a probably a loop drawing one character at a time with ExtTextOut which gives you full control over the placement of each character.
If you use ETO_OPAQUE to draw the first character in a column, and not with all of the others, then you will be permitted to kern the characters vertically if you need to.
Addendum
Roygbiv points to an interesting article that says that fonts whose names begin with an # behave differently then other fonts when you use CreateFont a font with an lfEscapement value of 2700, These special fonts produce upright characters while still advancing down the page. So while there is no way to do what you want for arbitrary fonts, you may be able to get it working using certain fonts.
Options for Displaying Text
Out of curiosity, i wrote a small console app to enum fonts and list the names. My Windows Server 2003 machine has not fonts with names beginning with #. But my Windows 7 machine has a few. All seem to be Chinese fonts though, I see no Japanese fonts in the default Windows 7 Ultimate install.
The correct answer is:
There are three methods to do this:
Using the Edit or RichEdit controls to render your text
Using the Uniscribe API
Using the TextOut function with a font face name that begins with an at sign (#).
Here is an article that discusses some of these approaches.
Fortunately, with Win32 you do not need to write code to rotate characters. To display text vertically on Windows 2000 and Windows XP, enumerate the available fonts as usual, and select a font whose font face name begins with the at sign (#). Then create a LOGFONT structure, setting both the escapement and the orientation to 270 degrees. Calls to TextOut are the same as for horizontal text.
In Win32, use the lfEscapement member of a LOGFONT structure to define the rotation of a font:
LOGFONT LogFont
LogFont.lfEscapement = 900; // 90 degreees rotated text
... // Many more initializations
HFONT newFont = CreateFontIndirect(LogFont);
SelectObject(hdc, newFont);
char tx[255];
strcpy(tx, "vertical text");
TextOut(hdc, x, y, tx, strlen(tx)); // draw a vertical font
For More Information see the online Help of LOGFONT structure and of the CreateFontIndirect Function
HFONT gui_font = CreateFont( -MulDiv( 9, GetDeviceCaps( GetDC( hWnd ), LOGPIXELSY ), 72 ),
0,
900, // here
0,
FW_THIN, 0, 0, 0,
DEFAULT_CHARSET,
OUT_DEFAULT_PRECIS,
CLIP_DEFAULT_PRECIS,
DEFAULT_QUALITY, FF_MODERN | FIXED_PITCH,
L"Segoe UI" );
Using lfEscapement (and if necessary lfOrientation) is superior in many ways to making the rectangle minimally wide (for instance: the dutch word 'wij' would have the 'i' and 'j' next to each other, because their combined width is less than the 'w'), or inserting a newline after each character.
The method this library uses sounds slow, but if do want it, it appears source code is provided:
http://www.ucancode.net/faq/CDC-DrawText-Drawing-Vertical-Text.htm
You may also find this discussion useful - http://www.eggheadcafe.com/forumarchives/win32programmergdi/Aug2005/post23542233.asp - apparently you need a vertical font (one beginning with #) and the API will take care of the rest.
As a quick hack type of answer, what happens if you use a standard control (CEdit for instance) and insert a new-line after every character typed?
Just an idea:
Did you try using DrawText or DrawTextEx using a very narrow rectangle that just fits the widest character?