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.
I didn't really get further. Everything looks normal if these assumptions and observations are correct:
- The freetype engine will cache every font for every different handle. - And as CreateFontIndirect returns a different handle on every call the engine will also cache as many fonts (if they are used). - The VB runtime will create a font for every control as they can be different. (At least it looks like that with dozens of calls to CreateFontIndirect and therefore many different font handles). - A font will only get deleted from cache if the program does so, not from wine itself. - As there is no error in the end about references not being 0 or so I guess that every GetObject also has a matching ReleaseObject. But the timing may be different to windows. (Tested with a simple app which works ok but still uses as many fonts as there are controls even if all are the same).
Is there a possibility to increase the GDI heap? Like that I could at least test if the app works ok besides this font problem. I ran it again on Windows and looked at the resources. It only uses 40 fonts while running, but I don't know about the startup. Comparing this to the wine stats it seems that Windows can use the same fonts for different controls. Or it does release and reallocate them on demand.
So I'm out of powder again. If anybody wants to test it I can send the application.
Thanks
bye Fabi