Re: Error in docs or misbehaving function?
I just tested it in Windows XP and Vista. I got the same erroneous result you did in XP, but got
the right result in Vista. It was apparently a little-known bug that got fixed. However, the
documentation seems to imply that the CONSOLE_FONT_INFO stuct will have all the correct information
about the font, but all of the examples I saw both from Microsoft and from external sources show
using GetCurrentConsoleFont to obtain the index, and then calling GetConsoleFontSize with that index
to get the size.
I couldn't find any documentation that says that should be necessary. On Vista (and probably
beyond), it probably isn't necessary, but to be safe, I'd recommend following that two-step method.
"Vincent Fatica" <vince@blackholespam.net> wrote in message news:49ebe1ce$1@news.vefatica.net...
GetConsoleFontSize() does give the correct answers.
What could those "physical units" possibly be? Whatever the console window
size, in chars x chars, that's what the methods below produce.
I repeat, the docs say:
"dwFontSize
A COORD structure that contains the width and height of each character in
the font, in logical units. The X member contains the width, while the Y member
contains the height."
What's there, in dwFontSize, is the number of characters per line and the number
of characters per column ... pretty perverted (actually inverted) notions of
"width and height of each character". By that way of thinking a font whose
height is 40 logical units is twice as high as one who's height is 80 logical
units (that's logical).
If GetCurrentConsoleFont() is working correctly then the docs would do well to
say:
"dwFontSize
A COORD structure whose X member is the number of characters per row of the
console window and whose Y member in the number of characters per column of the
console window." [better yet, call it dwConsoleWindowSize]
Of course, that info is readily obtainable from GetConsoleScreenBufferInfo().
On Sun, 19 Apr 2009 20:40:30 -0500, "Scot T Brennecke"
<ScotB@MVPs.spamhater.org> wrote:
|It does say "in logical units" rather than "in physical units", so the size returned may depend
on
|some other factors. What do you get if you try this API?:
|GetConsoleFontSize Function (Windows):
|http://msdn.microsoft.com/en-us/library/ms683165(VS.85).aspx
|
|"Vincent Fatica" <vince@blackholespam.net> wrote in message news:49ebc7da$1@news.vefatica.net...
|> The docs say:
|> **********
|> BOOL WINAPI GetCurrentConsoleFont(
|> __in HANDLE hConsoleOutput,
|> __in BOOL bMaximumWindow,
|> __out PCONSOLE_FONT_INFO lpConsoleCurrentFont
|> );
|>
|> typedef struct _CONSOLE_FONT_INFO {
|> DWORD nFont;
|> COORD dwFontSize;
|> } CONSOLE_FONT_INFO, *PCONSOLE_FONT_INFO;
|>
|> dwFontSize
|>
|> A COORD structure that contains the width and height of each character in
|> the font, in logical units. The X member contains the width, while the Y member
|> contains the height.
|> ********
|>
|> Yet this pair of functions (STD_OUT is a macro for GetStdHandle()):
|>
|> INT WINAPI _FONTW ( WCHAR *psz )
|> {
|> CONSOLE_FONT_INFO cfi;
|> GetCurrentConsoleFont(STD_OUT, FALSE, &cfi);
|> wsprintf(psz, L"%d", cfi.dwFontSize.X);
|> return 0;
|> }
|>
|> INT WINAPI _FONTH ( WCHAR *psz )
|> {
|> CONSOLE_FONT_INFO cfi;
|> GetCurrentConsoleFont(STD_OUT, FALSE, &cfi);
|> wsprintf(psz, L"%d", cfi.dwFontSize.Y);
|> return 0;
|> }
|>
|> tell me the font is 80x25 (which is actually the console window size in
|> characters).
|> --
|> - Vince
|
--
- Vince