Viktor,
I don't think so. Anyhow, I don't see a reason to make it complicated and mix the GC pointer concept with thread static variables either, it also seems wrongs, as AFAIU you can have multiple HDCs open in one thread, and HFONTs are paired with HDCs.
I just them trying to correct existing C code and do them 100% compatible with existing programs: win_tprn.prg and win_prn1.c not is my analysis. Now, with the existing code in the repository, TPrinter WIN_PRN increases GDIs objects because it's impossible eliminate the font created when creating the class or calling WIN_CREATEFONT, this is a bug, AFAIK.
[ Or (as you've suggested first), WIN_CREATEFONT() has to be changed to return HFONT, and let the higher level code handle these details, this makes the hbwin code simpler, but allows more mess ups on the app level. ]
Yes but would not be compatible with existing code ( I remember __hrbLoad :) and also introduces an interesting exercise, BTW. IMHO we could corrected or changed if new bugs are found or we opt for a better solution, this is the repository concept and so we can *learn*. Return hFont and create a DESTRUCTOR for TPrinter() to remove hFont is not difficult but I think we miss an opportunity. Best regards, -- Xavi _______________________________________________ Harbour mailing list (attachment size limit: 40KB) [email protected] http://lists.harbour-project.org/mailman/listinfo/harbour
