At 16:39 09.02.2004 +0000, Huw D M Davies wrote:
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.
My idea for caching the handles in CreateFontIndirect came from this:
GdiFont WineEngCreateFontInstance(DC *dc, HFONT hfont) --snip-- if(ret->hfont == hfont && !memcmp(&ret->xform, &dc->xformWorld2Vport, offsetof(XFORM, eDx))) {
Here it not only tests the properties but also the handles. So if the handles are different (as they are now from CreateFontIndirect) it will always create a new font. But removing this check didn't help either :)
I suspect your leak happens in the olefont implementation. You want to check that each hfont is destroyed when the IOleFont interface is released.
When are the fonts released? If a control creates a font and uses it until the dialog gets closed it doesn't help much. There will still be too many fonts while running. Or should the control create a font every time it has to draw anything and will release it again after? I can see releases but the reference counter never reaches 0 until the end of the program where all remaining fonts are cleaned up.
Sorry for asking, I don't know much about ole, fonts and stuff :)
bye Fabi