BuyLog In
Ticket T311768
Visible to All Users

FontsCache might be sharing GDI resources between different threads

created 9 years ago

[DevExpress Support Team: CLONED FROM T242111: NullReferenceException in DevExpress.Utils.Text.FontsCache.GetFontCacheByFont]
I have reverse engineered the applied logic and in all cases there was 1 common factor that is the cause of errors:

  1. Object reference not set to an instance of an object.
  2. Object is currently in use elsewhere.
    The error is the introduction of "DevExpress.Utils.Text.FontsCache.GetFontCacheByFont(Graphics graphics, Font font)".
    This class shares windows fonts between threads and that is STRICTLY FORBIDDEN.   Windows usage of GDI resources (during paint message handling but also stuff like "DevExpress.Utils.Text.TextUtils.GetStringSize(Graphics g, String text, Font font, StringFormat stringFormat, Int32 maxWidth, Int32 maxHeight, IWordBreakProvider wordBreakProvider, Boolean& isCropped)") is restricted to the thread that has created the GDI resource.
    In other words: "Only the thread that has created a font or window may use it, all other threads are not allowed to send windows paint messages to those windows".  Measuring the size of a font in a window is also some type of paint action (although invisible because only the size of the painted text is returned).
    Solution (only one of both should be implemented):
  3. The class "Text.FontsCache" must add the current-thread-ID to the ID that is used to store the created font in the cache.
  4. Each thread must make its own instance of the class "Text.FontsCache".
Show previous comments (9)
Sasha (DevExpress Support) 8 years ago

    Hello Andreas,
    To process your recent post more efficiently, I've created a separate ticket on your behalf: NullReferenceException is thrown in the GetFontCacheByFont method.
    I will address it shortly.

    RW RW
    Ruud Wildenberg 7 years ago

      Still no Fix ?

      DevExpress Support Team 7 years ago

        Hello Ruud,

        We have a couple of tickets with similar call stacks, but we are unable to reproduce these issues on our side, that is why we cannot fix them. I would also like to mention that usually such behavior occurs in multi-threading scenarios, when you access controls from a non-UI thread. If you face a similar issue, I suggest you review the How to: Make Thread-Safe Calls to Windows Forms Controls article. If this information does not help, the best way to proceed is to create a separate ticket in this regard and provide us with a sample where the issue is reproducible. It will help us to find the culprit.

        Sign in to comment on this post

        Disclaimer: The information provided on DevExpress.com and affiliated web properties (including the DevExpress Support Center) is provided "as is" without warranty of any kind. Developer Express Inc disclaims all warranties, either express or implied, including the warranties of merchantability and fitness for a particular purpose. Please refer to the DevExpress.com Website Terms of Use for more information in this regard.

        Confidential Information: Developer Express Inc does not wish to receive, will not act to procure, nor will it solicit, confidential or proprietary materials and information from you through the DevExpress Support Center or its web properties. Any and all materials or information divulged during chats, email communications, online discussions, Support Center tickets, or made available to Developer Express Inc in any manner will be deemed NOT to be confidential by Developer Express Inc. Please refer to the DevExpress.com Website Terms of Use for more information in this regard.