Point is ambiguous but complaints are about Appkit Framework code

[dpolito]

I am getting that Point is ambiguous issue in XCode 13 on the bitklavier project. It builds fine on XCode 12.4, but I get this string of errors in XCode all pointing to Appkit files from an include made in one of our files.

[kerfuffle]

There are two things called Point and the compiler doesn’t know which one you mean. It’s best to change all your Points to juce::Point instead.

[nicolasdanet]

Do you use the latest version of JUCE?

[dpolito]

The area in which it is confused is in AppKit code not ours. We already use juce::Point everywhere Point is needed in our code.

[dpolito]

Yes, I just downloaded it to my local machine a few days on last friday (1/07). Version 6.1.4

[nicolasdanet]

The “Reference to Point is ambiguous” error is a rather common topic in that forum.
Have you tried to include the macOS system headers in your project before the JUCE ones?

EDIT: Or there is that trick…

Is Point still broken? - reference to Point is ambiguous

This probably means you’ve pulled in a macOS system header yourself somewhere. You’ll need to prefix your points with juce:: or do something like this: #ifdef __APPLE__ #define Point CarbonDummyPointName #import <Foundation/Foundation.h> #undef Point #endif

[Solved] Unknown type name 'CarbonDummyPointName'

Hi guys, I’ve been upgrading my code to the juce 5 master and I have the old CarbonDummyPointName workaround in my code which is causing this error. I’ve noticed that most of the usages of this workaround in juce were removed by Timur in early 2016. I haven’t been able to gather why they are no longer necessary though. When I try to remove it for my own code, the old ambiguous Point error comes back. I’ve tried a few things, building 32 and 64 bit, JUCE_SUPPORT_CARBON enabled and disabled. …