Unicodified fontdlg (next try)
jack at itma.pwr.wroc.pl
Sun Nov 28 13:27:48 CST 2004
Thanks for looking at this.
Robert Shearman wrote:
> Initialising the whole string to zero just before it is about to be
> overwritten seems needlessly wasteful on CPU cycles and memory
> bandwidth. You seem to do this in a few places. Yes,
> MultiByteToWideChar can, in some cases, leave the string without a
> null terminator, but that only happens when there is insufficient
> buffer. In this case, the only way that can happen is if another
> thread modifies the buffer between the previous MultiByteToWideChar
> and the next one here. If you wanted to be really careful, you could
> always add "chFontw.lpszStyle[len-1] = '\0';" after to call to
I've just seen this was made somewhere in Wine source. That's why I've
done it as well. I've removed this.
> You seem to be freeing a buffer that the user passed in. How do you
> know it was allocated with HeapAlloc?
I have no idea why I did this. I've fixed this.
> You shouldn't need a cast here, unless lpTemplateName is a const.
I get compiler warnings when I remove this cast.
> This isn't something wrong with your patch, but is in the original
> code too. We shouldn't need to cast here, because if lpfnHook isn't
> using the right calling conventions or doesn't have the same number of
> parameters then we shouldn't be using CallWindowProc to start with.
The only difference betwen pcf->lpfnHook (that is declared as
LPCCHOOKPROC) and WNDPROC is LPCCHOOKPROC returns UINT
and WNDPROC LRESULT. Both use stdcall and have the same arguments, so I
think it is acceptable.
I'll send corrected patch to wine-patches.
-------------- next part --------------
A non-text attachment was scrubbed...
Size: 49458 bytes
Desc: not available
Url : http://www.winehq.org/pipermail/wine-patches/attachments/20041128/2716cf4d/fontdlg7.bin
More information about the wine-patches