Huw D M Davies wrote:
I had some fun with this a month or two ago. See the
test_margins_font_change test and calc_min_margin_size in the actual
code. The deal seems to be that for 'small' edit controls
EC_USEFONTINFO results in no margin. 'Small' is currently defined to
be smaller than the extents of the (four character) string "'**'",
that's close but not quite how Windows does it.
The fields in my case are 4 numbers.
Another interesting thing is that when it does set margins they are
often not symmetric left/right (although you tend to have to use
larger font sizes to see this) - it's presumably using some pair of
font metrics to set these and despite spending quite a while hunting I
drew a blank.
Now your problem could simply be that you don't have the font that the
app wants to use in this edit control...
What the "right" font should be is a bit of a mystery to me. From traces
with the font and edit debug channels turned on, it appears to me the
application was selecting "MS Shell Dlg". So in my test app, I
duplicated the selected font:
afont = CreateFont(-11, 0, 0, 0, 400, 0, 0, 0, DEFAULT_CHARSET,
OUT_DEFAULT_PRECIS, CLIP_DEFAULT_PRECIS, PROOF_QUALITY, DEFAULT_PITCH,
"MS Shell Dlg");
SendMessage(g_hControl,WM_SETFONT,(WPARAM)afont,0);
And indeed on Win2k, that produces an identical result to the Xilinx
app. On Wine, the font appears to be similar but not identical. As far
as the characters go, I can see that the '1' has an extra pixel to the
right at the bottom. Most of the other characters appear to be pixel
identical (though the '7' is rendered one pixel to the right of where it
is on Win2k). The biggest difference though, is that the numbers are
aliased on Wine, and not on Win2k. I'll see if I can figure out what
fonts are actually being used; I don't really know offhand how to go
about doing that.
