How to use standard windows terminal font and related problems.

[Roman Kohoutek]

Hello,

i am trying to figure out how to set to my TextBox.Font property to
'standard fixed width terminal font', or 'system oem font' or 'any other
monospaced/fixedwidth standard windows font'. There must be some 'trick' to
set it because i am not able to select 'terminal' font when developing my
application (using windows forms designer in MS VS .NET) and assign it to
TextBox.Font property. All i can do is to choose from installed fonts (and
there is no terminal font).
I am using LucidaConsole font now but it doesn`t fit my needs. Maybe there
is way how to change some 'properties of this font' (or my custom font
derived from LucidaConsole) to make letters and spaces not so wide.
Another problem i am trying to solve is how and what to tell to my font to
use ansii character set (extended ascii - to display properly graphical
characters). Some help pointed me to WinGDI.h (that i should some value from
there) but i dunno what exactly i should search for in that file. (Setting
GdiCharSet to 13 or 16 didn`t help :-(

Thank you for any ideas.

 

[Joe White]

The MSDN docs won't come right out and admit it, but I think that GDI+
only supports TrueType fonts, and not bitmapped fonts. Since Terminal
is a bitmapped font, you may not be able to use it in a .NET app.

Have you tried using Courier New? It doesn't have as much
intercharacter spacing as Lucida Console.

As far as the IBM extended-ASCII characters (the line-drawing characters
and such), you'll have to work with Unicode. If your program is
creating the strings to begin with, then just embed the Unicode
characters for the line-drawing characters (for example, the double
horizontal line is U+2554; use Character Map in Start > Programs >
Accessories to find the right codes). Note that these Unicode
characters might not work on end-user systems running Windows 98, though
they will work on NT, 2000, and XP.

If you're receiving ASCII-encoded strings (over a socket, from a file,
etc.) and need to convert them to Unicode, then I can't help -- the docs
are pretty scanty on these things. You could certainly do your own
character-by-character translation, and hard-wire each individual
character code into a switch statement, looking the codes up in
Character Map as you need them. Hopefully there's a better way using
the Framework, but I wasn't able to find one in a quick search through
the docs.

 

[Michael \(michka\) Kaplan [MS]]

The MSDN docs won't come right out and admit it, but I think that GDI+
only supports TrueType fonts, and not bitmapped fonts.

See

http://msdn.microsoft.com/library/en-us/gdicpp/gdiplus/gdiplusreference/enumerations/status.asp

or specifically:

NotTrueTypeFont - Indicates that the font retrieved from an HDC or
LOGFONT is not a TrueType font and cannot be used with GDI+.

Since Terminal
is a bitmapped font, you may not be able to use it in a .NET app.

That is correct, you can't.

Have you tried using Courier New? It doesn't have as much
intercharacter spacing as Lucida Console.

As far as the IBM extended-ASCII characters (the line-drawing characters
and such), you'll have to work with Unicode. If your program is
creating the strings to begin with, then just embed the Unicode
characters for the line-drawing characters (for example, the double
horizontal line is U+2554; use Character Map in Start > Programs >
Accessories to find the right codes). Note that these Unicode
characters might not work on end-user systems running Windows 98, though
they will work on NT, 2000, and XP.

Actually, they should work in most controls (like Label), though there are a
few where they won't (like TextBox).

If you're receiving ASCII-encoded strings (over a socket, from a file,
etc.) and need to convert them to Unicode, then I can't help -- the docs
are pretty scanty on these things.

Actually, the Encoding class is very well documented and works quite
well....

You could certainly do your own
character-by-character translation, and hard-wire each individual
character code into a switch statement, looking the codes up in
Character Map as you need them. Hopefully there's a better way using
the Framework, but I wasn't able to find one in a quick search through
the docs.

For the graphical characters the job is a bit harder, but you can easily
pinvoke to MultiByteToWideChar with the MB_USEGLYPHCHARS flag. Probably
using CP_OEMCP or 437...