AlertWindow - with rounded corners?

Hi Folks!

Does anybody know how to make a instance of AlertWindow appear with rounded corners?

Thanks in advance!

Pete

IIRC all you need to do is override drawAlertBox() in your LookAndFeel, and draw the background using Graphics::fillRoundedRectangle().

1 Like

Aha! Silly me - I should have thought. Many thanks!!

Pete

I tried that, but I get an ugly dark fill around the rounded corners!

Try setOpaque(false)?

1 Like

Thanks, David!!!

Where should i call setOpaque (false)? I’m trying to set it in the drawAlertBox method, but then the message box only flashes visible and is immediately automagically dismissed. This is super confusing behaviour.

What I do is call it immediately after the constructor.

  juce::AlertWindow *alertWindow = new juce::AlertWindow(WJX_StringLocale::sImStringToJString(title), WJX_StringLocale::sImStringToJString(message), juce::AlertWindow::NoIcon);
  alertWindow->setOpaque(false);

Hoping that helps!

Pete

Thanks for your help! I’ve only used the static methods e.g. AlertWindow::showOkCancelBox, that don’t give me the object. How do people show the alert window? There’s a big no no in the runModalLoop doc:

Note that you SHOULD NEVER USE THIS METHOD! Modal loops are a dangerous construct because things that happen during the events that they dispatch could affect the state of objects which are currently in use somewhere on the stack, so when the loop finishes and the stack unwinds, horrible problems can occur. This is especially bad in plugins, where the host may choose to delete the plugin during runModalLoop(), so that when it returns, the entire DLL could have been unloaded from memory! Also, some OSes deliberately make it impossible to run modal loops (e.g. Android), so this method won’t even exist on some platforms.

Is there some other way to make the AlertWindow visible?

[EDIT] But yes, it works like you suggest!

I have to admit this is super confusing. Even the default look&feel has rounded corners, that have opaque black background behind them. It seems the only way to get rid of those, for the static methods, would be to modify the JUCE source code. What am i not getting here?

To make visible:

  juce::AlertWindow *alertWindow = new juce::AlertWindow(WJX_StringLocale::sImStringToJString(title), WJX_StringLocale::sImStringToJString(message), juce::AlertWindow::NoIcon);
  alertWindow->setOpaque(false);
  alertWindow->addButton(WJX_StringLocale::sImStringToJString(okString), im::wj::ui::YesNoCancelResponse::yes, juce::KeyPress(juce::KeyPress::returnKey, 0, 0));
  
  // Run asynchronously
  alertWindow->enterModalState(
    true,
    juce::ModalCallbackFunction::create ([=](int result) {
      // Delete the alertWindow first - makes it easier
      // when debugging!
      delete alertWindow;

      if (okLambda != nullptr) {
        okLambda();
      }
    }),
    false); // true - take keyboard focus, handler, true means - delete when dismissed

I should note that I don’t use these JUCE alert Windows on iOS or macOS - I use calls to the native frameworks instead.

Pete

Awesome! Thank you very much @peteatjuce !

1 Like

If you need to patch your copy of the JUCE source code, go ahead - I’ve had to do that extensively for various reasons (e.g. tvOS support).

As a quick check, I think I’ve got 210 separate blocks of code changes in my version of JUCE.

Pete

Wow! I had a couple on another project. I had the Projucer post export script doing the patching, but found it anyway to be such a pain to maintain, so i decided to work this one without patching.

What i’ve done this time instead, is to just plain and simple duplicate the original JUCE classes and make my changes.

Previously i needed some additional parameters in the look and feel methods, so had to patch them. This time i’m just making my own variants of the components themselves without having to struggle with the limitations of the look and feel and the components’ interfaces. We’ll see how that goes. :crossed_fingers:

Once all the automation is set up, the patching approach is smooth i guess. ATM i feel easier fixing code than toolchains. Depends on the client too. I figure some might prefer vanilla JUCE with possibly more maintanance on the customized components.

Anyway, glad to hear i’m not the only one unable to make apps with vanilla JUCE. :slight_smile:

While I’ve found the Projucer to be useful for starting off a project, I’ve found that for many years that the easiest solution for me has been to maintain my various projects manually. There are many technical reasons that I’ve gone this route!

Best wishes, Pete

1 Like

I suppose createAlertWindow look and feel method works too, in case you need to use the static methods to create and show the alert window.