How to find if a font is installed on the system inside LabWindows CVI?

[DaPa1]

In a panel from a User Interface Resource file there are few Text Message controls with special fonts (this is an old project where UIR was already deigned and is used in production so cannot change it). At design time LabWindows detects if the font is installed in the current system and if not it shows this in the Edit Text Attributes dialog with a (not found) suffix, as shown in this picture Font Not Found

But on run time if the font is still not available the executable will pick up another font which might not fit the designed control size.

Is it possible to detect at startup if the font is available and if not to warn the user to install it? System details: oldish LabWindows-8.5 on Windows-10 64-bit. Did try to search Google and National Instruments but didn't find an answer. Also did try this code:

  char buff[1024];
  int xx = GetFontTypefaceName("Digital-7", buff);

but it always returns xx=9 and buff="Digital-7" indifferently if the font is installed or not on the test computer.

Here's at design time when LabWindows detects that the font is installed: Font found

[Ian.W]

GetFontTypefaceName() returns the length of the typeface name, and if the font does not exist it returns 0 and an empty string (length zero of course). Note there are 9 chars in "Digital-7".

I wonder if you have something going on with metafonts defined elsewhere in the project that would make Digital-7 exist. Check the function panel help for the Font Name parameter and then explore that old project for metafonts.

Hope this helps.

[DaPa1]

Thank you for suggestion. Just tested with a font which for sure doesn't exist, but GetFontTypefaceName still returns incorrect answer...

 

[Ian.W · Accepted solution]

Interesting. I tried a test like that and got 0 as the length and an empty string:

The closest I could easily get to your setup was CVI 2009 with the 2010 RTE. Maybe a bug that was fixed after 8.5. Or it is related to the Win32 API. 

[DaPa1]

Thank you Jan! That is also interesting result you got.Then most probably it's a bug in the 8.5 version.

As said the license we have is quite old (8.5.1) as this is a maintenance project... 

[Ian.W]

You might try the 2010 runtime (with the security patch too) from here. Backward compatibility in general is excellent. 

My only hesitation is whether there is a technical basis for trying a newer runtime to fix this specific problem.