GetTextExtentPoint32
Norman Diamond
trying to compute the size in pixels to display the text of a control,
before resizing the control. The control is in a dialog box.
On a Pocket PC the font of a dialog box's DC doesn't match the font of the
dialog box until I set it, therefore I set it, OK. If I don't set it then
GetTextExtentPoint32 yields wrong results. On a Smartphone if I do the same
thing and set the DC's font then GetTextExtentPoint32 yields wrong results.
On a Pocket PC if I don't call MapDialogRect then the results are still
wrong, but on a Smartphone if I do call MapDialogRect then the results end
up being wrong again.
If one doesn't experiment then maybe one will guess that on a Smartphone I
should both set the font and call MapDialogRect so they'll cancel each other
out like on a Pocket PC, but they don't, the result is still too small.
On a Pocket PC the call to GetWindowFont(hwndDlg) yields non-NULL so
GetStockObject is not called. During experiments on a Smartphone the
corresponding call to GetWindowFont(hwndControl) also yielded non-NULL, but
as mentioned above, selecting the correct font into the control's DC
resulted in GetTextExtentPoint32 returning unusable numbers.
The following code now is working but I really feel uncomfortable with the
inconsistencies in this code. Does anyone have ideas on how to do it right?
Partial C++ code:
#ifdef WIN32_PLATFORM_PSPC
hfDlgFont = GetWindowFont(hwndDlg);
if (hfDlgFont == NULL) {
// NULL はエラーを意味せずに system font を意味する。
hfDlgFont = (HFONT) GetStockObject(SYSTEM_FONT);
}
hdcDlg = GetDC(hwndDlg);
if (hdcDlg == NULL) {
return FALSE;
}
hgdiSomeFont = SelectObject(hdcDlg, (HGDIOBJ) hfDlgFont);
if ((hgdiSomeFont == NULL) || (hgdiSomeFont == (HGDIOBJ) GDI_ERROR)) {
return FALSE;
}
hfDcOldFont = (HFONT) hgdiSomeFont;
if (!GetTextExtentPoint32(hdcDlg, pszControlText, nControlTextLength,
&ControlTextSize)) {
return FALSE;
}
hgdiSomeFont = SelectObject(hdcDlg, (HGDIOBJ) hfDcOldFont);
if ((hgdiSomeFont == NULL) || (hgdiSomeFont == (HGDIOBJ) GDI_ERROR)) {
return FALSE;
}
if (ReleaseDC(hwndDlg, hdcDlg) != 1) {
return FALSE;
}
pControlTextRect->left = 0;
pControlTextRect->top = 0;
pControlTextRect->right = ControlTextSize.cx;
pControlTextRect->bottom = ControlTextSize.cy;
if (!MapDialogRect(hwndDlg, pControlTextRect)) {
return FALSE;
}
#endif //WIN32_PLATFORM_PSPC
#ifdef WIN32_PLATFORM_WFSP
hdcControl = GetDC(hwndControl);
if (hdcControl == NULL) {
return FALSE;
}
if (!GetTextExtentPoint32(hdcControl, pszControlText, nControlTextLength,
&ControlTextSize)) {
return FALSE;
}
if (ReleaseDC(hwndControl, hdcControl) != 1) {
return FALSE;
}
pControlTextRect->left = 0;
pControlTextRect->top = 0;
pControlTextRect->right = ControlTextSize.cx;
pControlTextRect->bottom = ControlTextSize.cy;
#endif //WIN32_PLATFORM_WFSP
Partial .rc code for export versions:
FONT 8, "MS Shell Dlg"
Partial .rc code for Japanese:
FONT 9, "MS Shell Dlg"
(By the way MSDN says MS Shell Dlg will not work in this environment but
fortunately it does work, at the moment. We cannot assume that every user
in east Asia wants Nina and everyone else wants Segoe Condensed. I
experimented installing other fonts and setting them in the registry. My
code which I'm not comfortable with does work with these fonts... this
week...)
James Brown
news:u75cIvC7...@TK2MSFTNGP03.phx.gbl...
I'm not following what the problem is, but will say this:
Calling GetDC results in a 'fresh' device-context. It has a default system
font selected into it. Even if you call GetDC(hwnd), do not expect the DC to
have the window's font selected into it. You must do that manually yourself,
this is standard Windows practice.
GetTextExtentPoint32 always returns correct results, based on the font you
currently have selected into the device-context.
Why do you expect GetWindowFont to return NULL?
--
James Brown
Microsoft MVP - Windows SDK
www.catch22.net
Free Win32 Tutorials and Sourcecode
Norman Diamond
news:FfSdndRkjIJ...@pipex.net...
> "Norman Diamond" <ndia...@community.nospam> wrote in message
> news:u75cIvC7...@TK2MSFTNGP03.phx.gbl...
>>
>> the dialog box until I set it, therefore I set it, OK. If I don't set it
>> then GetTextExtentPoint32 yields wrong results. On a Smartphone if I do
>> the same thing and set the DC's font then GetTextExtentPoint32 yields
>> wrong results.
>
I would expect correct code to work the same way on both Pocket PCs and
Smartphones. My code doesn't, and I have to code things so far differently
that I really don't think my code is correct.
> Calling GetDC results in a 'fresh' device-context. It has a default system
> font selected into it. Even if you call GetDC(hwnd), do not expect the DC
> to have the window's font selected into it. You must do that manually
> yourself, this is standard Windows practice.
Thank you. Then my Pocket PC code is probably pretty close to accurate.
But if I run my Pocket PC code on a Smartphone the results are garbage. Any
idea why?
> GetTextExtentPoint32 always returns correct results, based on the font you
> currently have selected into the device-context.
Yeah, always correct in that it's a horizontal count in some unit and a
vertical count in some unit, but the units aren't always pixels and I don't
always know how to convert the results to pixels.
> Why do you expect GetWindowFont to return NULL?
I have no expectation, but I prepared for the possibility because MSDN
describes the possibility. In asking my question, I mentioned all
information that I thought might help track down the problem. For example
had GetWindowFont returned NULL on a Smartphone then maybe that would have
been a clue.
Norman Diamond
news:FfSdndRkjIJ...@pipex.net...
> Why do you expect GetWindowFont to return NULL?
Addendum to my previous response:
http://msdn.microsoft.com/library/default.asp?url=/library/en-us/wceshellui5/html/wce50lrfwmgetfont.asp
* Return Values
* The return value is a handle to the font used by the control, or NULL if
* the control is using the system font.
* Remarks
* The WM_GETFONT message does not return a font handle if the message is
* sent to a dialog box created by the DialogBoxParam,
* DialogBoxIndirectParam, CreateDialogParam, or CreateDialogIndirectParam
* function.
According to that I really should have expected NULL. Anyway I prepared for
either NULL or non-NULL, and got non-NULL.
Norman Diamond
http://msdn.microsoft.com/library/default.asp?url=/library/en-us/wceshellui5/html/wce50lrfWMSETFONT.asp?frame=true
* Remarks
* Dialog boxes do not support DS_SETFONT. Applications can set the font
* for their controls manually.
* [...]
* When a dialog box uses the DS_SETFONT style to set the text in its
* controls, the system sends the WM_SETFONT message to the dialog box
* procedure before it creates the controls.
No on second thought that's not the reason. Even though my .rc files
specify a style that both isn't supported and makes the system take action,
the font ends up correct on both platforms. Only the size computations end
up different.
Norman Bullen
the results of SendMessage(hwnd, WM_GETFONT, 0, 0)?
You are using it to get the font (if any) associated with the dialog
window, not one of its controls. The MSDN document that you cited,
however, says dialog windows do not support WM_GETFONT. That being the
case, you probably always get NULL and then you use the system font to
measure to measure the size of the text. That may not be the same font
that the control will use to draw the text.
I would suggest that you ought to pass the handle of the control itself
rather than the handle of the dialog to your GetWindowFont() function.
I believe there is an error in the WM_SETFONT page that you cited:
Although the page is about WM_SETFONT it says "Dialog boxes do not
support DS_SETFONT. Applications can set the font for their controls
manually." Actually, dialog DO support DS_SETFONT (a style which causes
them to send WM_SETFONT messages to their controls) but they do not
support the WM_SETFONT and WM_GETFONT messages when sent to the dialog
window.
WM_SETFONT and WM_GETFONT are an example of what could have been a
really nice feature that saves a lot of code and headache for developers
but Microsoft failed to follow through. Suppose you could send
WM_SETFONT to any window and after that any call to GetDC() for that
window would get the device contest with the correct font already selected.
Actually, WM_SETFONT and WM_GETFONT are not supported inherently for all
Windows (even if older versions of documentation implied that this was
the case). They are supported only for Microsoft controls and for your
own windows if you write code to handle them. And if you write your own
code, you're responsible for saving the HFONT value for each window and
for selecting that value into the DC every time you need to draw the
window's text. I can't see that this saves anybody any effort at all.
Norm
--
--
To reply, change domain to an adult feline.
David Liebtag
I have a bad feeeling I'm about to put my foot in my mouth again, but I
can't resist asking some questions:
If you're trying to resize the control, why are you using the dialog font at
all? Dialogs don't normally have fonts and even if they did, why do you
care? Aren't you only trying to size the control? Why not simply send
WM_GETFONT to the control and use the result hFont to query the text extent.
Why are you using MapDialogRect at all? As far as I know, dialog units are
only used at dialog creation time when you're using a dialog template.
Since your dialog already exists, you should be able to work entirely in
pixels.
Does your post show your actual error recovery? When anything goes wrong,
you simply return without freeing any of the resources you've previously
acquired (such as the hDc)?
In short, I would have thought this would work:
hdcControl = GetDC(hwndControl);
hfontControl = (HFONT)SendMessage(hwndControl,WM_GETFONT,0,0) ;
hfontOld = SelectObject(hdcControl, hfontControl) ;
GetTextExtentPoint32(hdcControl, pszText, intTextLength, &sizeTextExtent) ;
SelectObject(hdcControl, hfontOld) ;
ReleaseDC(hwndControl, hdcControl) ;
SetRect(lprectTextRectangle,0,0,sizeTextExtent.cx,sizeTextExtent.cy) ;
David Liebtag
Norman Diamond
news:xuNWg.5390$Lv3...@newsread1.news.pas.earthlink.net...
> Norman Diamond wrote:
>> I don't like my code below but cannot figure out what to do about it.
>> I'm trying to compute the size in pixels to display the text of a
>> control, before resizing the control. The control is in a dialog box.
>
> results of SendMessage(hwnd, WM_GETFONT, 0, 0)?
Right-clicking the name "GetWindowFont" and going to the definition in
<windowsx.h>, I think that it expands to exactly the code that you wrote.
> You are using it to get the font (if any) associated with the dialog
> window, not one of its controls.
My code for Pocket PCs does that, yes. The reason is that when I got the
font from a control the results came out wrong. In the .rc file, a font can
be specified for the entire dialog but not for individual controls, so
"usually" no harm is done by getting the font from the dialog. Of course if
the application does a SetWindowFont (i.e. WM_SETFONT) then things will get
messed up. Notice that MapDialogRect requires the hwnd of the dialog not
the control.
My code for Smartphones had to omit that step entirely. Every experiment
that I did with trying to use an actual font yielded incorrect results.
That makes roughly three of the reasons why I'm uncomfortable with the code
I've come up with, i.e. exactly the reason I asked for help.
> The MSDN document that you cited, however, says dialog windows do not
> support WM_GETFONT.
Do you mean
http://msdn.microsoft.com/library/default.asp?url=/library/en-us/wceshellui5/html/wce50lrfwmgetfont.asp
which one of my other messages mentioned?
> That being the case, you probably always get NULL
That is exactly why I prepared for the possibility. That is exactly the
reason why I set a breakpoint in the debugger and checked, and posted the
fact that I got non-NULL.
> and then you use the system font to measure to measure the size of the
> text. That may not be the same font that the control will use to draw the
> text.
For some definition of "system font" other than the definition that Raymond
Chen and sometimes MSDN give to "system font", my expectation was the same
as yours. I'm not sure if Pocket PCs and Smartphones even have the old
dorky Windows 3.1-US version "system font" but of course they do have
default fonts, and it's possible to change default default fonts to
customized default fonts. So I did expect that when WM_GETFONT gets NULL
then the font would be this default, whether the default default or
customized default I don't know.
Anyway on Pocket PCs it turns out not to matter because I got non-NULL. And
on Smartphones even though I also got non-NULL (in experiments other than
the code that I posted), I had to stop using the returned font handle
because computations were always incorrect. I had to just use the default
whatever it is, as we're discussing here.
So yet again, here are reasons why I'm uncomfortable with my code and asked
for help.
> I believe there is an error in the WM_SETFONT page that you cited:
> Although the page is about WM_SETFONT it says "Dialog boxes do not support
> DS_SETFONT. Applications can set the font for their controls manually."
> Actually, dialog DO support DS_SETFONT (a style which causes them to send
> WM_SETFONT messages to their controls) but they do not support the
> WM_SETFONT and WM_GETFONT messages when sent to the dialog window.
Yeah now you're talking about
http://msdn.microsoft.com/library/default.asp?url=/library/en-us/wceshellui5/html/wce50lrfWMSETFONT.asp?frame=true
and one of my other messages quoted its self-contradiction on this point.
Norman Diamond
news:eQwuEXH7...@TK2MSFTNGP02.phx.gbl...
> If you're trying to resize the control, why are you using the dialog font
> at all?
Reason 1: When I got the font from the control, computations yielded
incorrect results. Reason 2: In the .rc file, a font can be specified for
the dialog but not for individual controls. Meanwhile, I dislike my code as
much as you do, which is why I posted asking for help.
> Why are you using MapDialogRect at all? As far as I know, dialog units
> are only used at dialog creation time when you're using a dialog template.
> Since your dialog already exists, you should be able to work entirely in
> pixels.
On Pocket PCs if I omitted the call to MapDialogRect then results were
wrong. On Smartphones if I included the call to MapDialogRect then results
were wrong. MSDN isn't very clear on whether the units are always pixels,
and as far as I can tell it's because Windows CE doesn't agree with Windows
CE on whether the units are always pixels.
I have an intuitive feeling that the dialog style DS_USEPIXELS might help
solve some of these problems, and maybe Microsoft had some reasons to define
this style for internal use, but until someone sues Microsoft again we're
not going to get a settlement publication of this API.
> Does your post show your actual error recovery? When anything goes wrong,
> you simply return without freeing any of the resources you've previously
> acquired (such as the hDc)?
Right, that was a work in progress, and I added some of those calls later.
But it's also kind of moot because in my experience none of those APIs ever
returned failure, it's just that the results of computations weren't what
they should be.
> In short, I would have thought this would work:
>
> hdcControl = GetDC(hwndControl);
> hfontControl = (HFONT)SendMessage(hwndControl,WM_GETFONT,0,0) ;
> hfontOld = SelectObject(hdcControl, hfontControl) ;
> GetTextExtentPoint32(hdcControl, pszText, intTextLength, &sizeTextExtent)
> ;
> SelectObject(hdcControl, hfontOld) ;
> ReleaseDC(hwndControl, hdcControl) ;
> SetRect(lprectTextRectangle,0,0,sizeTextExtent.cx,sizeTextExtent.cy) ;
You and I thought the same thing. Then I experimented. Did you experiment,
on either Pocket PCs or Smartphones? Either you'll see why I asked for
help, or ... um, "or else". Either way, please let me know how it behaves
for you.
Norman Diamond
no longer works. Eyeballing the results, it looks like every height and
width is computed to be about double what they should be, and one control
gets pushed off the right-hand side of the screen.
In previous experiments, that's what a Smartphone was doing if my Pocket PC
code ran on a Smartphone.
Back to square 1. Anyone know how to do it right?
"Norman Diamond" <ndia...@community.nospam> wrote in message
news:u75cIvC7...@TK2MSFTNGP03.phx.gbl...
Norman Diamond
be called, but there is still something odd about the way the result is
accurate sometimes and inaccurate other times. I seem to have solved it now
on a slightly larger collection of samples by adding enough horizontal space
for roughly half of a character. This is unnecessary on some platforms and
is not suggested at all by MSDN (as far as I can see) so I still feel
uncomfortable with it. On the other hand the results do not look ugly on
any of the platforms that I've tried, even when it isn't necessary. The
full text gets displayed instead of being truncated, and excess white space
is not noticeable.
Does anyone think this is really the right way to do it? Or is there a
right way?
The addition is ((ControlTextSize.cy + 1) / 2) in the second-to-last line:
hfControlFont = GetWindowFont(hwndControl);
if (hfControlFont == NULL) {
// NULL はエラーを意味せずに system font を意味する。
hfControlFont = (HFONT) GetStockObject(SYSTEM_FONT);
}
hdcControl = GetDC(hwndControl);
if (hdcControl == NULL) {
return FALSE;
}
hgdiSomeFont = SelectObject(hdcControl, (HGDIOBJ) hfControlFont);
if ((hgdiSomeFont == NULL) || (hgdiSomeFont == (HGDIOBJ) GDI_ERROR)) {
ReleaseDC(hwndControl, hdcControl);
return FALSE;
}
hfDcOldFont = (HFONT) hgdiSomeFont;
if (!GetTextExtentPoint32(hdcControl, pszControlText, nControlTextLength,
&ControlTextSize)) {
SelectObject(hdcControl, (HGDIOBJ) hfDcOldFont);
ReleaseDC(hwndControl, hdcControl);
return FALSE;
}
hgdiSomeFont = SelectObject(hdcControl, (HGDIOBJ) hfDcOldFont);
if ((hgdiSomeFont == NULL) || (hgdiSomeFont == (HGDIOBJ) GDI_ERROR)) {
ReleaseDC(hwndControl, hdcControl);
return FALSE;
}
if (ReleaseDC(hwndControl, hdcControl) != 1) {
return FALSE;
}
pControlTextRect->left = 0;
pControlTextRect->top = 0;
pControlTextRect->right = ControlTextSize.cx +
((ControlTextSize.cy + 1) / 2);
pControlTextRect->bottom = ControlTextSize.cy;
Norman Bullen
Are you allowing for non-client areas in your control size?
Prior to running this code, have you actually assigned the correct font
to the control? Two ways to do that: either the dialog does it for you
if you use the DS_SETFONT style and the correct font is specified in the
dialog resource, or you send WM_SETFONT messages yourself with the
correct font handle.
Have you checked the return value from each of these API calls? Are they
as expected? Do you get any NULL returns from GetWindowFont()? Do you
get a NULL return from either SelectObject()?
Norman Diamond
> Norman Diamond wrote:
>> I seem to have solved it now on a slightly larger collection of samples
>> by adding enough horizontal space for roughly half of a character. This
>> is unnecessary on some platforms and is not suggested at all by MSDN (as
>> far as I can see) so I still feel uncomfortable with it. On the other
>> hand the results do not look ugly on any of the platforms that I've
>> tried, even when it isn't necessary. The full text gets displayed
>> instead of being truncated, and excess white space is not noticeable.
>>
>> Does anyone think this is really the right way to do it? Or is there a
>> right way?
>>
>> pControlTextRect->top = 0;
>> pControlTextRect->right = ControlTextSize.cx +
>> ((ControlTextSize.cy + 1) / 2);
>> pControlTextRect->bottom = ControlTextSize.cy;
>
> Are you allowing for non-client areas in your control size?
I didn't think that static controls (plain text with no border) had
non-client areas. A few platforms seemed to agree with my opinion, i.e.
some didn't truncate the strings even when I didn't add that horizontal
fudge factor.
For radio buttons I took the control's height as originally delivered by
Windows CE instead of using the computed height of the text, and widened the
width by an amount equal to the height to allow for the width of the button,
plus around 4 more pixels for whitespace and borders. For edit controls I
had to widen the height a few pixels more than expected. Anyway some
platforms didn't need the additional widening by ((ControlTextSize.cy + 1) /
2) but other platforms truncated the text if this wasn't added.
> Prior to running this code, have you actually assigned the correct font to
> the control? Two ways to do that: either the dialog does it for you if you
> use the DS_SETFONT style and the correct font is specified in the dialog
> resource, or you send WM_SETFONT messages yourself with the correct font
> handle.
I use DS_SETFONT and MS Shell Dlg. (By the way MSDN implies that MS Shell
Dlg won't work here for two reasons: the development environment isn't
US-English, and sometimes the target environment can't use Tahoma or Segoe
Condensed or whatever Eurocentric font is this month's favoured font. But
oddly this part of it does work.)
> Have you checked the return value from each of these API calls?
Yes, in the debugger I set breakpoints on every return FALSE; and none of
them got hit.
> Are they as expected?
I'm not sure how to answer. There are around 6 different kinds of units
involved in dialog box measurements and originally I thought
GetTextExtentPoint32 returned something that would have to be mapped by
MapDialogRect. So much for expectations.
> Do you get any NULL returns from GetWindowFont()?
Oddly no. In the debugger I set another breakpoint just after that call,
and of course that breakpoint did get hit. I checked the font handle and it
was always non-NULL, even when I was prepared for NULL.
> Do you get a NULL return from either SelectObject()?
No.
Norman Bullen
nControlTextLength (when used in this code) exactly match what they will
be when the control is finally painted? You're not losing the last
character due to failure to allow for a NUL terminator, are you? How do
you get those values?
If you increase the width of these controls without concern for running
into other controls to their right, why not simply make them as wide as
possible in the dialog editor and then not worry about it?
Norman Diamond
> Have you checked that the values of pszControlText and nControlTextLength
> (when used in this code) exactly match what they will be when the control
> is finally painted?
In most cases I fetched the text from the control in the first place. The
dialog proc (or sometimes the .rc file in case of statics) had already set
the controls' texts and then called this function to resize and reposition
the controls. Truncation was occuring with statics and radio buttons.
Originally I tried calling MapDialogRect as recommended by MSDN but then the
sizes came out too large, sometimes twice the correct height and twice the
correct width.
The exceptions were edit boxes in which case the text string passed to
GetTextExtentPoint32 was a string of 9's the same length as the limit that
was set on user input.
> You're not losing the last character due to failure to allow for a NUL
> terminator, are you?
Exactly the opposite, in some of my experiments. One of the arguments to
GetTextExtentPoint32 is the length of the text. If the length includes the
string's NUL terminator then the returned result is too large. The length
argument must be the length of the displayable text only.
> How do you get those values?
Usually GetWindowTextLength followed by GetWindowText. For edit boxes as
mentioned above, _T("999") or whatever, together with _tcslen of the
_T("999") or whatever.
> If you increase the width of these controls without concern for running
> into other controls to their right,
I don't understand your question. The reason for computing the size needed
for each control is so that each control will be resized as necessary and
repositioned to the right or below other controls that have already been
resized or repositioned.
> why not simply make them as wide as possible in the dialog editor
Then some controls would be pushed off the right-hand side of the screen for
no purpose at all, as controls to their left will be vandalously wide.
There really is a purpose in computing the necessary size and position of
each control.
> To reply, change domain to an adult feline.
I already live in the domain of an adult feline.