Check “Configuration Properties, General, Character Set” and also, have a look at “Linker, System, SubSystem” make sure it’s set to “Windows (/SUBSYSTEM:WINDOWS)”
Hm… the Character Set is set to Multi-Byte, and the subsystem is indeed set to ““Windows (/SUBSYSTEM:WINDOWS)”” for both Debug and Release. (so far, so good then?)
I’m guessing that the error happens in the START_JUCE_APPLICATION macro? The error happens because of a difference in TCHAR. The system include are declaring it one way (narrow or wide) and then something is changing.
No waste at all. Analyzing the problem, is there any way that the JUCE headers could be modified to detect this condition and generate some sort of #error ?
Hm… so it seems that the 3rd party library happened to be including Windows.h, and I was including the master library header after JuceHeader.h… instantly causing the WinMain conflict.
I wonder if there’s an indicator of some kind for knowing if Windows.h is being included or not.
<windows.h> causes WINAPI to get defined, and JUCE uses LPSTR in the START_JUCE_APPLICATION macro for the declaration of WinMain. This is actually a bug in JUCE…
Try changing LPSTR to LPTSTR in juce_Initialisation.h and see if it works where it would previously generate an error.
Jules designed juce_Initialisation.h to not need the include of <windows.h>, which is great. But if windows.h is included before the JUCE headers then there’s a problem, since it defines WINAPI and causes the alternate macro definition for START_JUCE_APPLICATION. I believe that this is the proper fix:
/*
To start a JUCE app, use this macro: START_JUCE_APPLICATION (AppSubClass) where
AppSubClass is the name of a class derived from JUCEApplication.
See the JUCEApplication class documentation (juce_Application.h) for more details.
*/
#if JUCE_ANDROID
#define START_JUCE_APPLICATION(AppClass) \
juce::JUCEApplication* juce_CreateApplication() { return new AppClass(); }
#elif JUCE_WINDOWS && defined (WINAPI)
#define START_JUCE_APPLICATION(AppClass) \
static juce::JUCEApplicationBase* juce_CreateApplication() { return new AppClass(); } \
int WINAPI WinMain (HINSTANCE, HINSTANCE, LPTSTR, int) \
{ \
juce::JUCEApplication::createInstance = &juce_CreateApplication; \
return juce::JUCEApplication::main(); \
}
#elif JUCE_WINDOWS && defined (_UNICODE)
#define START_JUCE_APPLICATION(AppClass) \
static juce::JUCEApplicationBase* juce_CreateApplication() { return new AppClass(); } \
int __stdcall WinMain (void*, void*, const wchar_t*, int) \
{ \
juce::JUCEApplication::createInstance = &juce_CreateApplication; \
return juce::JUCEApplication::main(); \
}
#elif JUCE_WINDOWS
#define START_JUCE_APPLICATION(AppClass) \
static juce::JUCEApplicationBase* juce_CreateApplication() { return new AppClass(); } \
int __stdcall WinMain (void*, void*, const char*, int) \
{ \
juce::JUCEApplication::createInstance = &juce_CreateApplication; \
return juce::JUCEApplication::main(); \
}
#else
#define START_JUCE_APPLICATION(AppClass) \
static juce::JUCEApplicationBase* juce_CreateApplication() { return new AppClass(); } \
int main (int argc, char* argv[]) \
{ \
juce::JUCEApplication::createInstance = &juce_CreateApplication; \
return juce::JUCEApplication::main (argc, (const char**) argv); \
}
#endif
The issue is actually the following; if I include windows.h at any point, intentionally or not (ie: a library includes it without me knowing), after the JuceHeader.h, the following version of WinMain becomes active (thus causing the “‘WinMain’: function cannot be overloaded” error):
[code]/*
To start a JUCE app, use this macro: START_JUCE_APPLICATION (AppSubClass) where
AppSubClass is the name of a class derived from JUCEApplication.
See the JUCEApplication class documentation (juce_Application.h) for more details.