Windows macro conflicts in keyboard.hpp

[Google Code Exporter]

What steps will reproduce the problem?
Compile this program:
----------
#include <windows.h>
#include <wm/keyboard.hpp>
int main() { return 0; }
----------

What is the expected output? What do you see instead?

1>------ Build started: Project: wm_test, Configuration: Debug Win32 ------
1>Compiling...
1>main.cpp
1>C:\pt\externals\include\wm/keyboard.hpp(193) : error C2143: syntax error
: missing '}' before '('
1>C:\pt\externals\include\wm/keyboard.hpp(193) : fatal error C1903: unable
to recover from previous error(s); stopping compilation
1>Build log was saved at
"file://c:\d\wmtest\build\wm_test.dir\Debug\BuildLog.htm"
1>wm_test - 2 error(s), 0 warning(s)
========== Build: 0 succeeded, 1 failed, 1 up-to-date, 0 skipped ==========


What version of the product are you using? On what operating system?
libwm 0.2.0 on Windows Vista (64-bit)

Please provide any additional information below.

The problem is that a handful of enumerant names used in keyboard.hpp
conflict with macros defined in various Windows header files.  If
windows.h is included prior to keyboard.hpp, the preprocessor attempts
to expand these enumerants as macros, causing all sorts of mayhem.
(This seems to be related to issue #28, but I'm not certain whether it's
a duplicate.)

It's generally impossible to force a particular include order for windows.h
because so many other headers require it. This is a pretty
big portability problem right now.

The patch below fixes things for me. I can't claim that it's a perfect
solution, but it seems no worse than the current situation:

Index: keyboard.hpp
===================================================================
--- keyboard.hpp        (revision 8)
+++ keyboard.hpp        (working copy)
@@ -3,6 +3,13 @@

 #include <wm/export.hpp>

+// These cause known macro conflicts under Windows
+#undef DELETE
+#undef MOD_ALT
+#undef MOD_CONTROL
+#undef MOD_SHIFT
+#undef REGISTERED
+
 namespace wm
 {
        /// Keyboard symbols and utility functions

Original issue reported on code.google.com by [e-mail] on 22 Apr 2010 at 7:54