On Mon, Feb 09, 2004 at 05:03:40PM +0100, Fabian Cenedese wrote:
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.
Huw.