If the imported proto file has a function called GetMessage, TurboLink will generate a corresponding .h/cpp matching that interface, and including all of its standard includes.
Unfortunately, the include chain also pulls in WinUser.h, included through an upstream Windows.h include, which defines a macro:
This ultimately causes the generated file to not compile because the macro has renamed the function.
This is a known problem within the Windows API, where many function names are redefined via macro to FunctionNameW or FunctionNameA, but still something that can cause problems with TurboLink. For now, I'm using #undef GetMessage after the include in the generated file, but others might find better workarounds or a proper solution that avoids the accidental upstream inclusion of windows.h.
If the imported proto file has a function called GetMessage, TurboLink will generate a corresponding .h/cpp matching that interface, and including all of its standard includes.
Unfortunately, the include chain also pulls in WinUser.h, included through an upstream Windows.h include, which defines a macro:
This ultimately causes the generated file to not compile because the macro has renamed the function.
This is a known problem within the Windows API, where many function names are redefined via macro to FunctionNameW or FunctionNameA, but still something that can cause problems with TurboLink. For now, I'm using
#undef GetMessage
after the include in the generated file, but others might find better workarounds or a proper solution that avoids the accidental upstream inclusion ofwindows.h
.