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. -- Huw Davies [EMAIL PROTECTED]
