> Sorry but I do not understand. > WIN_CREATEFONT() only has a live font eliminating the prior and this font is > saved for each DCS to make sure it is removed. > It's the logic of the existing function maybe have to be called > WIN_CREATEFONTWPDC :) because it is not a function of creating generic fonts > rather to print fonts with TPrint()
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. IMO the Harbour HDC/HFONT holder structure (the same you added) needs to be moved to GC. [ 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. ] Unfortunately I can't explain it better than I did, maybe someone else will. Brgds, Viktor _______________________________________________ Harbour mailing list (attachment size limit: 40KB) Harbour@harbour-project.org http://lists.harbour-project.org/mailman/listinfo/harbour
