Re: WINEFILE: Eliminate use of windowsx.h

[Mike McCormack]

Martin Fuchs wrote:
> "Eliminating" windowsx.h sounds like you consider this header file a bad thing.
> I don't think so - it provides a bunch of very usefull type safe macro definitions.
> (SelectFont, ListBox_SetSel, Button_SetCheck, ...)
>
> I understand you want to eliminate some useless warnings printed by
> newer GCC versions. Wouldn't it be better to correct the wrong warnings
> of GCC instead?

Please see my previous email for a discussion of the problem:

http://www.winehq.org/pipermail/wine-devel/2006-March/045250.html

Despite containing some useful macros, those macros are somewhat broken 
as they are ignorant of UNICODE, so cannot be "fixed" by simple 
conversion to inline functions.

Mike

WINEFILE: Eliminate use of windowsx.h

[Robert Shearman]

Mike McCormack wrote:
> Martin Fuchs wrote:
> > "Eliminating" windowsx.h sounds like you consider this header file a
> > bad thing.
> > I don't think so - it provides a bunch of very usefull type safe
> > macro definitions.
> > (SelectFont, ListBox_SetSel, Button_SetCheck, ...)
> >
> > I understand you want to eliminate some useless warnings printed by
> > newer GCC versions. Wouldn't it be better to correct the wrong warnings
> > of GCC instead?

I agree with this comment that we shouldn't remove the uses of these
macros, but I have to disagree with them being typesafe - they aren't.
> Please see my previous email for a discussion of the problem:
>
> http://www.winehq.org/pipermail/wine-devel/2006-March/045250.html
>
> Despite containing some useful macros, those macros are somewhat
> broken as they are ignorant of UNICODE, so cannot be "fixed" by simple
> conversion to inline functions.

Unicode isn't a problem as "void *" could simply be used, but there are
other compatibility reasons why inline functions shouldn't be used.

WINEFILE: Eliminate use of windowsx.h

[Martin Fuchs]

2006/3/18, Robert Shearman :
> Mike McCormack wrote:
> > Martin Fuchs wrote:
> > > "Eliminating" windowsx.h sounds like you consider this header file a
> > > bad thing.
> > > I don't think so - it provides a bunch of very usefull type safe
> > > macro definitions.
> > > (SelectFont, ListBox_SetSel, Button_SetCheck, ...)
> > >
> > > I understand you want to eliminate some useless warnings printed by
> > > newer GCC versions. Wouldn't it be better to correct the wrong warnings
> > > of GCC instead?
>
> I agree with this comment that we shouldn't remove the uses of these
> macros, but I have to disagree with them being typesafe - they aren't.

Well, I meant kind of "type safe" in this sense: You can use
SelectFont instead of
SelectObject and now you are working with a font handle - not just any type
of GDI handle. Or you can use SelectBitmap instead of the plain
SelectObject API call...
Of course the macros are not type safe in the sense of C++ type safety.

Regards,

Martin

WINEFILE: Eliminate use of windowsx.h

[Mike McCormack]

Robert Shearman wrote:
> > Despite containing some useful macros, those macros are somewhat
> > broken as they are ignorant of UNICODE, so cannot be "fixed" by simple
> > conversion to inline functions.
>
> Unicode isn't a problem as "void *" could simply be used, but there are
> other compatibility reasons why inline functions shouldn't be used.

Using the following example:

#define ComboBox_AddString(hwndCtl, lpsz) \
         ((int)SendMessage((hwndCtl), CB_ADDSTRING, 0L, 
(LPARAM)(LPCTSTR)(lpsz)))

In Wine source, UNICODE is not defined.  So should the above be using 
SendMessageW/LPCWSTR or SendMessageA/LPCSTR?

Furthermore, using an inline function requires that we've included 
winuser.h to get the definition of SendMessageA/W, whereas windowsx.h on 
its own doesn't require that.

The commctrl.h macros don't have this problem as they define A/W 
versions of the macros.  I am in the process of adding inline functions 
to commctrl.h, and will submit a patch for that soon.

Mike

WINEFILE: Eliminate use of windowsx.h

[Robert Shearman]

Mike McCormack wrote:
> Robert Shearman wrote:
> > > Despite containing some useful macros, those macros are somewhat
> > > broken as they are ignorant of UNICODE, so cannot be "fixed" by simple
> > > conversion to inline functions.
> >
> > Unicode isn't a problem as "void *" could simply be used, but there are
> > other compatibility reasons why inline functions shouldn't be used.
>
> Using the following example:
>
> #define ComboBox_AddString(hwndCtl, lpsz) \
>         ((int)SendMessage((hwndCtl), CB_ADDSTRING, 0L, 
> (LPARAM)(LPCTSTR)(lpsz)))
>
> In Wine source, UNICODE is not defined.  So should the above be using 
> SendMessageW/LPCWSTR or SendMessageA/LPCSTR?

Either "void *" as I mentioned above or only the LPARAM cast for Wine 
source files, and LPCTSTR still for Winelib.
> Furthermore, using an inline function requires that we've included 
> winuser.h to get the definition of SendMessageA/W, whereas windowsx.h 
> on its own doesn't require that.
>
> The commctrl.h macros don't have this problem as they define A/W 
> versions of the macros.  I am in the process of adding inline 
> functions to commctrl.h, and will submit a patch for that soon.

Well, I guess I am relieved that you're not putting an #error at the top 
of the include file like you did with windowsx.h.

WINEFILE: Eliminate use of windowsx.h

[Mike McCormack]

Robert Shearman wrote:
> > Using the following example:
> >
> > #define ComboBox_AddString(hwndCtl, lpsz) \
> >         ((int)SendMessage((hwndCtl), CB_ADDSTRING, 0L, 
> > (LPARAM)(LPCTSTR)(lpsz)))
> >
> > In Wine source, UNICODE is not defined.  So should the above be using 
> > SendMessageW/LPCWSTR or SendMessageA/LPCSTR?
>
> Either "void *" as I mentioned above or only the LPARAM cast for Wine 
> source files, and LPCTSTR still for Winelib.

You seem to miss the point about SendMessage.  A or W?  You have to 
choose, and you don't know what is appropriate.

Mike