Unicodified fontdlg (next try)

[Jacek Caban]

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 
> MultiByteToWideChar.

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.

>
> Rob
>
I'll send corrected patch to wine-patches.

Jacek

-------------- next part --------------
A non-text attachment was scrubbed...
Name: fontdlg7.diff
Type: text/x-patch
Size: 49458 bytes
Desc: not available
Url : http://www.winehq.org/pipermail/wine-patches/attachments/20041128/2716cf4d/fontdlg7.bin