MessageBoxOptions creates opposite results for AlertWindow vs NativeMessageBox

On a Mac, building with Juce 6…

Using the same MessageBoxOptions object, and going between using AlertWindow::show vs NativeMessageBox::show, I get opposite button order in the dialog box’s layout. This issue is more than cosmetic – since those methods return an int that is “the index of the button that was clicked”, you actually get opposite results for them!

    MessageBoxOptions options = MessageBoxOptions()
        .withIconType (MessageBoxIconType::WarningIcon)
        .withTitle ("Here's a question for you...")
        .withMessage ("Will it be Yes/No or No/Yes?")
        .withButton ("Yes")
        .withButton ("No");
    
    int buttonClicked;
    
    buttonClicked = NativeMessageBox::show (options);
    DBG ("the index of the button that was clicked was: " + String (buttonClicked));

    buttonClicked = AlertWindow::show (options);
    DBG ("the index of the button that was clicked was: " + String (buttonClicked));

Clicking the Yes button in the NativeMessageBox returns a 0, but clicking the Yes button in the AlertWindow returns a 1.

So, is this an idiosyncrasy of the two formats, or a bug? If it’s a consistent idiosyncrasy, I could program around it… but if it’s a bug that will be fixed, then my workaround would break when it was fixed.

This sounds familiar. It’s definitely worth testing with JUCE 7 to see whether the issue has already been fixed.

Yeah, good to check that, but a build with JUCE v7.0.2 produced the same results.

Were you able to verify this on your end?

Circling around to this issue again, here are screenshots produced by the code in my first post, in macOS:


So, as you can see, for the same MessageBoxOptions, JUCE’s alert window is ordering the buttons in reverse order from what the native messages box does. And because both AlertWindow::show and NativeMessageBox::show return “the index of the button that was clicked”, a “Yes” click returns 1 for the JUCE alert window but a 0 from a native alert window.

Per Apple’s Human Interface Guidelines, the JUCE AlertWindow’s placement of the default button is backwards:

Place buttons where people expect. In general, place the button people are most likely to choose on the trailing side in a row of buttons or at the top in a stack of buttons. Always place the default button on the trailing side of a row or at the top of a stack. Cancel buttons are typically on the leading side of a row or at the bottom of a stack.

Upon further investigation, part of this confusion arises from a conflict of Mac vs Win standards. In Windows, native message boxes are arranged opposite from what Mac does. Here is the same code, generating a NativeMessageBox in Windows:

Screen Shot 2022-10-28 at 5.31.17 PM

So the JUCE AlertWindow layout is following the Windows standard, with the affirmative/default option on the left, rather than the Mac standard with it on the right.

1 Like

@reuk In testing the differences between macOS and Windows displays of NativeMessageBox, I did find what seems to be a bug in Windows.

With this code, NativeMessageBox::show should return either a 0 for Yes, or a 1 for No. But on Windows, it returns a 2 for No.

    MessageBoxOptions options = MessageBoxOptions()
        .withTitle ("Here's a question for you...")
        .withMessage ("Yes or No?")
        .withButton ("Yes")
        .withButton ("No");
    
    int buttonClicked = NativeMessageBox::show (options);
    DBG ("NativeMessageBox::show - index of the button clicked: " + String (buttonClicked));
1 Like