'Rectangle' : ambiguous symbol


#1

Hi,

I include windows and gdi before juce_WithoutMacros.h but get

1>C:\git\patrick\vflib\include\vf/ui/vf_Facade.h(43): error C2872: ‘Rectangle’ : ambiguous symbol
1> could be 'C:\Programme\Microsoft SDKs\Windows\v7.0A\include\wingdi.h(3989) : BOOL Rectangle(HDC,int,int,int,int)'
1> or ‘c:\git\juce.vc10\src\gui\graphics\contexts…/geometry/juce_Rectangle.h(42) : juce::Rectangle’

Does anyone know a workaround for this?

best regards,

Patrick


#2

Just use an explicit namespace - juce::Rectangle.


#3

I’m trying to switch to the juce module branch and have exactly the same problem: when building using sources from the modules branch, visual c++ complains about ambiguous Rectangle and I have to explicitely add the juce:: namespace, while when I build against the two month old non-module juce tree it shows no issue… I’m puzzled, the environment is the same, and the compilation flags are the same. Juce is included using the supplied ‘juce.h’ file.


#4

There used to be a macro that defined Rectangle as juce::Rectangle, but I dropped it because using something like that is just a really nasty hack.

You should just use an explicit namespace, or maybe don’t include the windows headers in files that don’t need them, so that there’s no clash.


#5

I’m having exactly this problem while trying to arrange some existing sources in “juce module” fashion.

One of these .cpp files needs windows.h so I put an #include for it into the main “juce_module.cpp” file.

This causes all the other .cpp files that use Rectangles to complain like shown above.

What is the preferred way to cope with this?


AAX resizing Bug and fix
#6

define NOGDI before any Windows headers:

#if defined(_MSC_VER)

#define NOGDI
#include <windows.h>
#include <WinBase.h>
#include <atomic>

#endif

You can also define WIN32_LEAN_AND_MEAN after defining NOGDI (if that’ll work for you).

Rail


Not a big deal, but
#7

i also suggest define NOMINMAX before too :smiley:


#8

Very cool! I run into this issue from time to time when writing native Win32 code alongside JUCE code, I usually hack it out via super annoying header include ordering. I think this way better.