Hello, quickie Q here just to avoid going down a wrong path. Hope I didn’t miss something when searching!
I’m calling MenuBarModel::setMacMainMenu() in the constructor of my DocumentWindow, and I get an immediate crash. The debugger gets a little confused around here, but it appears that deeper down, we’re touching an uninitialized Array… but all my classes appear to be finished their construction and initialization…
Before I dig further, might I ask if calling MenuBarModel::setMacMainMenu() in the constructor is too early, and if so, what’s the best way to do it? Or it’s very useful just to know that I should be able to do it, so I can gird my loins and get dirty with the debugger.
I think that when you call it, it’ll immediately start trying to build a menu arrangement, which will invoke calls to the ApplicationCommand stuff to find out what’s on there, and that’ll probably try to call your not-ready-yet window object.
I typically call the setMainMenu things in JUCEApplication::initialise, after the main window has been created. I guess you could also safely call it before the window gets created, just not in the middle of creating it!
And this opens a very interesting can of worms that’s been in the back of my head. (whew, what a metaphor!)
My application has no main window - or at least, logically it has no main window. I’m now wondering if that does really work for Juce - because Windows applications need a main Window (is that true?)
Regardless, I have a clear workaround - call MenuBarModel::setMacMainMenu() from the code that creates my DocumentWindow… thanks, as always!
[OK, this didn’t actually work. I’m still getting a crash in MenuBarModel::addListener() - it seems that the Array that contains listeners is corrupt or uninitialized because the crash is at Array::contains, and the underlying memory pointer seems bogus… however, this is low on my list of priorities for now. I’ll repost in this thread when I’ve found a solution to it!)
Well, there’s nothing stopping you from running a windowless app in Windows, but it makes it a bit tricky to interact with it. You could always use a SystemTrayIconComponent though.
Eh, it sounds like a Bad Idea, though, doesn’t it? Last thing I want to do is to confuse the poor user. I think we’ll end up having a tiny “home window” with a few global controls on it.
I’ll post here again when I resolve the MenuBarModel issue (I edited my previous post to include more info)… be well!
I’m still getting a crash in MenuBarModel::addListener() - it seems that the Array that contains listeners is corrupt or uninitialized because the crash is at Array::contains, and the underlying memory pointer seems bogus… however, this is low on my list of priorities for now. I’ll repost in this thread when I’ve found a solution to it!)