Crash with non-GUI app and AlertWindow

General JUCE discussion
1

Hi,

for much improved robustness, I am scanning for installed plugins in a separate process rather than in the host itself. This nicely discards all the loaded plugins and leaves the host in a clean state.

The scanner has no main window or menu bar and only shows a single AlertWindow to indicate progress. Therefore I created a “Non-GUI” project with Introjucer and manually did a initialiseJuce_GUI(); and shutdownJuce_GUI(); around the actual scanning code. This worked fine until updated to the latest tip (v1.54.21), but now it is broken (Mac):

2011-07-10 18:32:07.089 Scanner[23180:10b] *** Terminating app due to uncaught exception 'NSInternalInconsistencyException', reason: 'Error (1002) creating CGSWindow' 2011-07-10 18:32:07.090 Scanner[23180:10b] Stack: ( 2528202731, 2539621947, 2528202187, 2528202250, 2447446183, ... )
The crash happens when alertWindow.enterModalState() gets around to toFront();, namely when sending the message [window makeKeyAndOrderFront: nil];

The NSWindow seems to be ok, so I wonder what’s wrong with my code? Did I miss something important concerning the GUI/Non-GUI notion? What does CGSWindow mean?

Any hint is appreciated!

2

Since you are using a GUI, why would you try to make it a non-GUI app…?

3

I don’t need a window and a menu bar.

And I need to launch it as a child process. This does not work easily with a Mac app, where the executable is nested in the bundle. At least it makes things more complicated.

4

You said you’re using an AlertWindow, so how is that not a window!? Whether or not it needs a menubar is irrelevant - if you’re running an event loop, it’s got to be a GUI app, and for any windows, you need an event loop.

5

Hmm. Thanks for clarifying. I first ran a FakeMessageThread, but that didn’t help, so I made it a regular GUI app now which does all its work in the initialise() method and then quits.

I still wonder whether it would be better to kick off a one-time event shortly after the app completed its initialisation, and have that event (message) perform the scan?

6

Yes, probably better to do that.

7

Good to know, thanks for the tip.

Now my PerformOnMessageThread class comes in handy :slight_smile: