FontFamily Collection Refresh Question

  • Thread starter Thread starter Bryan Kinkel
  • Start date Start date
B

Bryan Kinkel

From what I can tell, the FontFamily() collection does not receive
notification when system fonts are changed while a .NET application is
running.

For example, you have your .NET app running. The user adds or removes a
series of fonts using the Windows Control Panel. The FontFamily() collection
in your app will remain unchanged. The same applies if any app, including
the running .NET app, uses Win32 calls such as AddFontResource() to install
a font. The FontFamily() collection will not update itself until the .NET is
restarted.

This behavior differs significantly from functionality in the Classic VB
Fonts() collection (going back to VB1.0). The Fonts() collection was always
refreshed when the system font list changed.

I have posted a sample VS2005 project demonstrating the issue at the
following URL:

http://loseyourmindcom.setupmyblog.com/?p=14

For me, this is a serious for. I've been trying to rewrite a font manager
application. If the FontFamily() collection is not updated, then I can't
draw newly installed fonts using GDI+. And using the PrivateFontCollection()
object would be a lot of work (and a sizable kludge).

1. Is this behavior by design? Why?
2. Is there any chance of getting it fixed for Visual Studio 2005?

Thanks,

Bryan Kinkel
(e-mail address removed)
 
Hi Bryan,

Thanks for your post!

Yes, with the project you provided, I can reproduce out the problem.
FontFamily internally uses InstalledFontCollection class to do the query.
However, I found InstalledFontCollection class also has this issue.
InstalledFontCollection class internally encapsulates GDI+ to do the actual
work.

After doing some search, I found a bug regarding this issue in our internal
database. However, this is a Windows OS GDI+ bug, not .Net bug.

Currently, the Windows OS team has tracked this bug in the database. We can
only hope it will be fixed in future.

Finally, I think such issue is more GDI+ related than Winform related. So
microsoft.public.dotnet.framework.drawing newsgroup may be suitable place
to post in the future.

Thanks

Best regards,
Jeffrey Tan
Microsoft Online Community Support
==================================================
When responding to posts, please "Reply to Group" via your newsreader so
that others may learn and benefit from your issue.
==================================================
This posting is provided "AS IS" with no warranties, and confers no rights.
 
Hi Al,

Thanks for your feedback.

Yes, I see your concern. However, this newsgroup is not managed means that
Microsoft newsgroup support currently does not provide support for .Net
GDI+. If you post GDI+ questions in framework.drawing newsgroup, you may
get useful responses from experienced community members in drawing
newsgroup.

If you still can not get useful response in that newsgroup, you may have to
contact Microsoft PSS for case support.

Thanks for your understanding.

Best regards,
Jeffrey Tan
Microsoft Online Community Support
==================================================
When responding to posts, please "Reply to Group" via your newsreader so
that others may learn and benefit from your issue.
==================================================
This posting is provided "AS IS" with no warranties, and confers no rights.
 
Jeffrey,

Are you responding to my thread? Or another thread here?

I still want to continue a discussion about GDI+ font list refreshing. But
I'm not going to post in a non-managed group if MS staff won't see it there.

-- Bryan
 
Jeffrey,

Here is what I don't understand about this behavior - the classic VB Fonts
collection has received and correctly processed system font change
notifications since VB1. Now I realize .NET is a totally different beast.
But I'm not sure how it could be a Windows bug.

When a font is installed in Windows, an application typically uses one of
the AddFontResource() API calls. If the font is not private to the
application, then the app sends out a WM_FONTCHANGE message to inform top
level windows that, well, the fonts have changed.

It is then up to the other applications to process or discard this message -
a graphics app might run an EnumFonts() call to refresh its own internal
font list for example.

I would be very interested in hearing more specifics about the bug in the OS
that prevents a .NET app from refreshing its own internal font list.

Thanks,
Bryan Kinkel
 
Hi Bryan ,

Thanks for your post!

Based on the information regarding this bug, it is actually the bug of
native GDI+ InstalledFontCollection class, which is used by .Net GDI+
wrapper.

Thanks

Best regards,
Jeffrey Tan
Microsoft Online Community Support
==================================================
When responding to posts, please "Reply to Group" via your newsreader so
that others may learn and benefit from your issue.
==================================================
This posting is provided "AS IS" with no warranties, and confers no rights.
 
Jeffrey,

On more question about this - is this bug scheduled to be fixed in Visual
Studio 2005 SP1?

Thanks,

Bryan
 
Hi Bryan,

Sorry, because this is a windows OS bug, I do not think there is anything
we can do in VS2005 side. Also, in the bug record, I did not find any
information regarding when it will be fixed in GDI+.

Anyway, if you still feel this is critical to you, you may contact
Microsoft PSS for a hotfix. Thanks

Best regards,
Jeffrey Tan
Microsoft Online Community Support
==================================================
When responding to posts, please "Reply to Group" via your newsreader so
that others may learn and benefit from your issue.
==================================================
This posting is provided "AS IS" with no warranties, and confers no rights.
 
Jeffrey,

First you said it was a bug in the OS. Then you said it was a bug in GDI+.
Now you are saying it is a bug in the OS again.

Which is it? GDI+ or OS? Or both?

Can you please provide more *specific* details as to the nature of the bug
or bugs? I really want to know what is going on under the hood when a new
font is installed and how GDI+ deals with it.
Anyway, if you still feel this is critical to you, you may contact
Microsoft PSS for a hotfix. Thanks
Click to expand...

I'm not seeking a hot fix. I'm looking for some clear information as to the
nature of the bug and what is going on under the hood between the OS and
GDI+. This will help me formulate a work around in my code.

Bryan Kinkel



"Jeffrey Tan[MSFT]" said:
Hi Bryan,

Sorry, because this is a windows OS bug, I do not think there is anything
we can do in VS2005 side. Also, in the bug record, I did not find any
information regarding when it will be fixed in GDI+.

Anyway, if you still feel this is critical to you, you may contact
Microsoft PSS for a hotfix. Thanks

Best regards,
Jeffrey Tan
Microsoft Online Community Support
==================================================
When responding to posts, please "Reply to Group" via your newsreader so
that others may learn and benefit from your issue.
==================================================
This posting is provided "AS IS" with no warranties, and confers no
rights.
Click to expand...
 
Hi Bryan,

GDI+ is implemented in gdiplus.dll in C:\WINDOWS\WinSxS directory. It is a
system dll included with Windows OS. So this bug is in the GDI+ portion of
Windows OS.

Currently, the detailed bug information is not public available.

Hope this makes sense to you.

Best regards,
Jeffrey Tan
Microsoft Online Community Support
==================================================
When responding to posts, please "Reply to Group" via your newsreader so
that others may learn and benefit from your issue.
==================================================
This posting is provided "AS IS" with no warranties, and confers no rights.
 
Yes, it makes sense. I just never considered GDI+ to be part of the OS. I
always thought it was part of the .NET Framework or just another runtime
DLL. (In fact I think gdiplus.dll ships with Visual FoxPro 9 as well.)
Currently, the detailed bug information is not public available.
Click to expand...

It is a shame the bug is not publicly available. It just amazes me that some
of the simplest things taken for granted in Classic VB simply don't work due
to bugs in .NET related subsystems.

But thank you for your follow-up.

Bryan Kinkel

"Jeffrey Tan[MSFT]" said:
Hi Bryan,

GDI+ is implemented in gdiplus.dll in C:\WINDOWS\WinSxS directory. It is a
system dll included with Windows OS. So this bug is in the GDI+ portion of
Windows OS.

Currently, the detailed bug information is not public available.

Hope this makes sense to you.

Best regards,
Jeffrey Tan
Microsoft Online Community Support
==================================================
When responding to posts, please "Reply to Group" via your newsreader so
that others may learn and benefit from your issue.
==================================================
This posting is provided "AS IS" with no warranties, and confers no
rights.
Click to expand...
 
Hi Bryan,

Yes, the bug detailed record may have some Microsoft confidential
information in it, so it is not suitable for public publishing. Thanks for
your understanding.

Best regards,
Jeffrey Tan
Microsoft Online Community Support
==================================================
When responding to posts, please "Reply to Group" via your newsreader so
that others may learn and benefit from your issue.
==================================================
This posting is provided "AS IS" with no warranties, and confers no rights.
 
Back
Top