Pixels to points

[Laurence Jackson]

If you're used to specifying your font sizes in pixels, you may need the following small function for use with the new FONT NEW statement, which accepts only point heights.

function PixelsToPoints (Pixls as long) as single

local hDC as dword
local PixPerInchY as long

hDC = GetDC(%HWND_DESKTOP)
PixPerInchY = GetDeviceCaps(hDC, %LOGPIXELSY)
ReleaseDC %HWND_DESKTOP, hDC
PixelsToPoints = 72 * Pixls / PixPerInchY

end function

Although the FONT NEW help seems to imply that the fontname$ parameter is obligatory, it seems happy to accept a null string here with an appropriate font family code in the pitch& parameter.

[Barry Marks]

Although the FONT NEW help seems to imply that the fontname$ parameter is obligatory, it seems happy to accept a null string here with an appropriate font family code in the pitch& parameter.

It seems to take anything you give it. When I typed "WingDing" for the fontname$ (incorrectly leaving off the final s) it didn't have a problem with that. It just used the existing font.

The help says if it can't find the specified font it tries to provide some replacement. I suspect that's the explanation.

Barry

[Chris Boss]

This effect has more to do with the Windows API than it does the FONT NEW command.

FONT NEW likely calls the CreateFont API function.

When you define a Font in Windows, Windows maps the font to the closest font it can find. There are a number of attributes for fonts and Windows tries to find the best match. This means that Windows may not even return the same font you request, but an alternate one.

If font mapping didn't exist you find a number of programs not being able to display text at all. Windows is smart enough to return the best match, even for missing fonts.

[Paul Squires]

I ended up having to use FONT NEW last night when I was writing XPRINT code. The XPRINT SET FONT requires the handle from a FONT NEW function - I was using a regular Windows font handle. The FONT NEW handles are different (mine had numbers like '3', '4', etc...). I guess PB9 assigns its own internal handle numbers to the fonts. This is a little bit of a 'gotcha' if you are expecting to be able to intermix the handles - they are very different. Paul needs to read the Help file more closely!

[Michael Mattias]

This is a little bit of a 'gotcha' if you are expecting to be able to intermix the handles - they are very different.

If the PB doc don't say it's a valid (Windows') system object handle and may be used as such, never assume it is.

Eg, PB doc says clearly PB file handles (#1,#2... FREEFILE()) are "internal, private" handles; but DDT-created dialog and control handles are valid window handles.

[Paul Squires]

Make no mistake, the help file is clear on the point. It refers that "a unique PowerBASIC handle" is returned. This is similar to the scenario with PB file handles. This was a user error - me!

[Michael Mattias]

Perhaps this was an "ERROR 1", but it was a golden opportunity for me to remind people that 'mixing and matching' in the absence of documentation is at best a crapshoot.