The PopUp us a context menu (and also a menustrip menu). It gets its name from Java's JPopUp.

Agui does not have a message box for several reasons and I will not be adding one.

I do not feel 1 'look' or style would fit everyone's needs. It's a bit subjective to me.

Most messageboxes block the calling thread until a response from the user which allows the nice:
if(MessageBox(....) == YES)

You could probably quickly roll one out for your game and needs with images and buttons to your liking. I did this for my game.

Or there is always the native dialogs addon.

What I mean is that, MessageBoxes usually need icons, which agui will not provide. Sometimes you can float your buttons right, or left. You may want a title bar, you may not. You may want an X button, you may not. In addition, you would have to provide all the OK, Cancel, Yes, No, Abort, Retry, Fail, texts because I cannot assume everyone's game is English.

And this is only for Gui Applications. Often game message boxes might have checkboxes and other assortments.

For the PopUp, I felt I could make it generic enough to be useful in a variety of situations. But I did not feel this for the messagebox.

Agui is designed for you to subclass all of its Widgets and make your own sort of GuiFactory to your games' needs. This is why every Widget has only 1 constructor that takes in pointers to its children. This is so that, if you make a custom button, then you can use that to make a custom scroll bar. Then your custom ListBox can use your custom scrollbar.

This means that any of Agui's parameters can be fine tuned at 3 levels:
The Widget Level
The Composite Widget Level
The Instance Level.

Ex: Scroll rate.
Your subclassed scrollbar can override the default scroll rate.
Then, your ListBox can override this scroll rate.
Then one of your ListBoxes might have a unique set scroll rate.

This gives the user a lot of control and flexibility which I like.

Well, I don't have a message box in my gui either. :/ I mean, you could make one real quick with just a few widgets and then put it in a function and run it. I mean, the library can't be expected to do everything. And there are already other options available, like the native dialogs addon, so use that.

Sounds like Agui could provide more functionality than the other allegro gui's then if added

.Net, Java, QT, WxWidgets, etc all have a message box. I'd say its pretty standard even in games.

In fact I'm going through a wiki of GUIs and googling them and message boxes and they all seem to have them. Just saying

I could do this easily enough in my gui I suppose. Create a new graphics context (window), give it a gui and a few buttons and wait for a close signal. Truly modal is harder though, because then you have to use a native dialog. So again, why not just use the native dialog addon?

I don't understand the worry about this being modal. I can simulate modal if I want by setting a flag to skip running my entire logic or just other GUI logic when I pop this modal box up, but I think a good number of games don't have 100% true modal anyway.

I think of games like WoW that have a message box come up when a battleground is ready. Accept/Decline, oh and you can keep doing other things I'm just a message that allows you to click buttons to do a certain action. No need for me to block anything.

I just don't know that many decent games that use the native OS's message box in the game itself. That's a little cheesy if you ask me.

1. I've already created my own with Agui. I'm simply trying to give feedback to help give the library more functionality and be more on par with professional GUI libraries.

2. Of course I am lazy. Everyone using Allego is lazy. Everyone using .Net is lazy. Being lazy is why libraries exist. We don't want to have to rewrite things that have consistency to them, and my argument is other professional guis have basically standardized the basic message box. if I want a non standard message box in .Net its up to me to make my own but 99% of the time the flexible standard message box works and save me time because I am lazy.

"Nice way" can be somewhat objective but here is basically what I did with mine.

I create a member variable of AGuiMessageBoxResult::MessageBoxResult which holds the result and that's what I return from Show(). The MessageBox class holds the frame, buttons, and label widgets. They are predefined Yes, No, Cancel, OK. In the show you set the msg and title and what combinations of the buttons you want. The order is always the same. It's not that big of a deal.

The MessageBox class is derived from ActionListener and 'this' passed to the controls inside it. It overrides the actionPerformed method to check which button was clicked and sets the MessageBoxResult class variable accordingly, which Show returns. By default it's set to None.

The "trick" is that Show() is to be called every frame since with this you can't have a true blocking messagebox. In my game code I handle this with flags.

For example in my Login game state when the player clicks exit I pop up an "Are you sure" msgbox. In the Login state class when Exit is clicked I set a flag, that my Update method in Login state class will do the showing of this to check the return value to see what was pressed.

I then simply disable/enable all other controls. On my login screen I do this manually, but I'm assuming if I made a panel or something I could enable/disable the entire panel to do this for the controls I want to enable/disable.

For online games you don't want to block the game logic from running (which I assume the native msg box would do). You simply just want to block other GUI widget messages, but allow the game to still run. This gives me that.