Modules branch and exceptions

I just moved an app over to the modules branch, and noticed that my JUCE_TRY and JUCE_CATCH_ASSERT were all compiling to nothing, so I…

#define JUCE_CATCH_UNHANDLED_EXCEPTIONS 1

In my AppConfig.h file, but this then made DeletedAtShutdown class start to complain about not knowing anything about the JUCEApplication class.

So…

in juce_events.h

#if JUCE_CATCH_UNHANDLED_EXCEPTIONS
#ifndef __JUCE_APPLICATIONCOMMANDTARGET_JUCEHEADER__
#include "../juce_gui_basics/commands/juce_ApplicationCommandTarget.h"
#endif

#ifndef __JUCE_APPLICATION_JUCEHEADER__
#include "../juce_gui_basics/application/juce_Application.h"
#endif
#endif

Also in mac_messagemanager JUCEApplicationBase::sendUnhandledException is an invalid static function, so change that to

JUCEApplication::sendUnhandledException

Shouldn’t JUCE_CATCH_UNHANDLED_EXCEPTIONS default to 1 ? I think was this how it was defined in master.

I also missed this chunk of code that I added manually to JuceHeader.h (stupid collisions with c structs)

#if (JUCE_MAC || JUCE_IOS) && ! JUCE_DONT_DEFINE_MACROS
#define Component       JUCE_NAMESPACE::Component
#define MemoryBlock     JUCE_NAMESPACE::MemoryBlock
#define Point           JUCE_NAMESPACE::Point
#define Button          JUCE_NAMESPACE::Button
#endif

/* "Rectangle" is defined in some of the newer windows header files, so this makes
 it easier to use the juce version explicitly.
 
 If you run into difficulties where this macro interferes with other 3rd party header
 files, you may need to use the juce_WithoutMacros.h file - see the comments in that
 file for more information.
 */
#if JUCE_WINDOWS && ! JUCE_DONT_DEFINE_MACROS
#define Rectangle       JUCE_NAMESPACE::Rectangle
#endif

#endif

Ok, thanks.

I can’t do it like you suggest though, because the events modules isn’t dependent on the gui module, so mustn’t include any of its headers. I’ll try to figure something out.

And those mac defines shouldn’t actually be needed any more, since it doesn’t include any carbon headers. What are you doing that’s causing a problem?

My own stupid code still depends on some carbon crap!

Ah, well it’s probably neater to patch your code to specify the namespace for those classes (or just pop those macros in your own header). I don’t really think they belong in the library any more.