Thank you Xavi, it's perfect this way. (pls try to use our coding style, this saves me valuable time).
Brgds, Viktor On 2009 Nov 22, at 20:31, Xavi wrote: > Ok, I change WIN_CREATEFONT to return GC solvent the bug and adapt TPrinter > for this in attache files. > > -- > Xavi > > Viktor Szakáts escribió: >>>> 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. >> I perfectly understand this. >>>> [ 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. >> Please note it's not a coincidence I told you to feel free modifying >> WIN_CREATEFONT(). Compatibility in this case is secondary, firstly the name >> of the function changed 2 times in the last 1.5 years (without any >> complaint), second, in xhb (where this function comes from originally), this >> function is _not even a public one_. >> Hence: compatibility is secondary, I guesstimate that waste majority of >> users use it via the .prg level class. >> But, I believe it's possible to solve it using the method I outlined. It's >> up to you to consider them. >> I can't add more to this thread at this point. >> Brgds, >> Viktor > > <win_tprn1.zip> _______________________________________________ Harbour mailing list (attachment size limit: 40KB) Harbour@harbour-project.org http://lists.harbour-project.org/mailman/listinfo/harbour
