Definition of T and conflicts with other win libs

I ran into this problem, as mentioned in other posts, and the forum helped me work out what it was (thanks) - no thanks to the crappy error messages in VC++.

The exact same code was fine on Mac, of course.

I tried to use the without/define macros files, but it required too much juggling to put it in the exact place each time, seeing as I have classes inheriting from both libs.

So could you please add a juce_UndefineMacros.h? It seems to make more sense to bracket the offending includes and leave the bulk of code a bit cleaner.


i don’t understand why you want to undefine juce macros ?
no that should not be used. unless you don’t want them at all (still i don’t understand why, but…).

the right way is to do like this instead:

#include "juce_WithoutMacros.h" #include "fucked_up_header.h" #include "juce_DefineMacros.h"

that would clean up compilation errors when multiple defining T or such…

I tried that, but if other header files include juce.h as well then there seems to be a double jeopardy - and I don’t want everything to have access to the problematic includes, but some do need to refer to the classes that use them.

Having said that, I ended up with the multiple definitions of WinMain and did quite a lot of re-ordering, so maybe it would work.

But in many other posts people have done undefs, and Jules seemed OK with it - I’m just suggesting an extra approach.

It looks like the withoutMacros approach would have to be global and every file would need the define macros just before it did anything.

The whole thing was a big rigamarole, in short.


Yeah, this happened to us with winnt.h from windows.h and the T() text macro. It was with the OpenGL code from the demo.

Took quite a while to figure out, maybe someone could make some clever preprocessing code to detect this and give a warning if the files are included in the wrong order.

So windows.h before juce.h is good.
juce.h before windows.h doesn’t work and gives unintuitive errors about the code in winnt.h

Hmm - if there was a way of throwing up a sensible warning, then I’d have added it. I added comments about this next to the T() macro, assuming that people would look at that if it was causing problems, but there’s no way to add code to the windows headers that would produce a warning.

You could test if windows.h is included first and #error out with a message saying to include it first if not or so forth…