>> I hacked some more and need an advice. I changed font.cpp: CreateFontIndirectW >> a bit. Instead of always allocating a new gdi object it has a list of already >> allocated font objects and first tests if there was already a font allocated >> with the same logical properties (LOGFONTW). If so it just returns the >> existing HFONT and doesn't allocate a new one. With this change my >> VB app with the many controls comes up and is almost usable. Some >> fonts on the registers of the tab control look quite strange. But besides >> that it works. >> >> Now is this a reasonable change (apart from its hacky implementation >> now :) ? Is the function CreateFontIndirect allowed to do something like >> this? Are there more things I should test than just the ones in the >> LOGFONTW struct? If anybody is interested in a screenshot (the >> funny fonts go down by about 20 degrees :) just raise your hand. > >No, this isn't right. You can convince yourself of this by a quick >test program on Windows; initialize a LOGFONT and then call >CreateFontIndirect twice, you'll get two different hfonts back. > >I suspect your leak happens in the olefont implementation. You want >to check that each hfont is destroyed when the IOleFont interface is >released.
I also sometimes had this in mind as I couldn't find OLEFontImpl_Release calling OLEFontImpl_Destroy in my logs. The reference pointer never seems to become 0. So I will have a look into this. Thanks bye Fabi
