I wait for new Realise.
And I wait too for your super new animation

Wow Bob, this is ridiculously useful, and when I use the term ridiculously I mean "to degrees man had not yet conceived". There are about a zillion applications to this... and I'm about to create one.

I do have one question: How do I destroy the menu after it's been created? I used your demo template above to create mine (it worked like a charm), but I need a way to not just hide it, but remove it from memory so it can be recreated later without wasting more memory space... I looked through the operators for the POPUP struct but couldn't find anything relevant to this.

Help?

[EDIT: Yeah deleting the damn popup didn't actually work in practice. I got an exception]

Also, I've got build 4792, but I don't have the POPUPOPTION struct... Hard to work without that, especially because I can't find any other way to set an option as unavailable...

Ok, it's POPUP_OPTION now, that should probably be stated above.

Finally, is there a way to set tooltips while hovering over an option? I saw that options have the "hint" variable, but it doesn't seem to be used at all. Should I be making tooltips appear manually?

About deleting popups/options, I think there's still a bunch of bugs in the cleanup code somewhere, so make sure to thoroughly test every part where you explicitly delete them. AFAIK, things work just fine in the quick attachment code, so I recommend you use that as a reference - it was a field for the popup widget, helped me fix a lot of tiny bugs and work around some quirks.

That one didn't make it into the current version. Either add it to the class (should be easy, tooltip code is surprisingly elegant) or try looping over gPopupRegionIndex to find regions for a given popup. In gPopupRegionIndex, regionId property refers to MOUSE_REGION::IDNumber, classId to POPUP::id. Do MSYS_GetRegionUserData( pRegion, 1 ) to see if it triggers an option or a subpopup, MSYS_GetRegionUserData( pRegion, 0 ) to check which one.

Also there are some things painfully missing from the pop-up system. One is manually setting availability for lines, i.e. not relying on any functions to test availability. Second is setting color for each line individually - which may allow us to make menu headers in a different color. Also stuff like deciding what color an option's highlight would be. It's very cosmetic stuff, but many pop-ups currently use these things to good effect for many purposes, it does feel like I'm missing features I would've had if I could use the game's original pop-up system...

bool gOptAvail[2];

bool checkAvail(INT8 i){
  return gOptAvail[i];
}

// o1, o2 are POPUP_OPTIONs
o1->setAvail( new popupCallbackFunction(&checkAvail,0) );
o2->setAvail( new popupCallbackFunction(&checkAvail,1) );

gOptAvail[0] = FALSE; //option 1 unavailable
gOptAvail[1] = TRUE; //option 2 available

I think your issue with buttons overlapping the pop-ups is because buttons get marked "dirty" and are then redrawn on top of everything else. It should theoretically be possible to just push your pop-ups so that they draw even later than that, causing buttons - even dirty ones - to be drawn below them. I'll see if I can't find a way to do this.

For manually disabling lines...

As for setting colors - I kinda kept reminding myself about it when working on the popup class, but always found more important stuff that needed fixing before I got around to adding more features.

1 - the popup system draws its boxes (all of them, including the ones defined by my popup class - after all, it is just a wrapper) before buttons are drawn. This can't be changed globally since some popups have buttons in them (sector summary, militia assignment...) and there is no easy way of splitting the display process for things defined by my class and the old system.

That one didn't make it into the current version. Either add it to the class (should be easy, tooltip code is surprisingly elegant) or try looping over gPopupRegionIndex to find regions for a given popup. In gPopupRegionIndex, regionId property refers to MOUSE_REGION::IDNumber, classId to POPUP::id. Do MSYS_GetRegionUserData( pRegion, 1 ) to see if it triggers an option or a subpopup, MSYS_GetRegionUserData( pRegion, 0 ) to check which one.

@Headrock: I thought that the method that creates mouse areas for each menu line would be the right place to add tooltips. IIRC They are created and destroyed every time the box is shown and destroyed when hiding it. It should work as long as you properly destroy the tooltips when hiding the menu.

I see, that would explain it. Well as I said, these problems are less relevant to me because I completely destroy+recreate the box every time it is activated, which IMHO you should've done with your attachment popups as well - no need to create them all in advance.

Also, there's no logistical reason to create mouse-regions only when a menu is rendered - they should exist from the moment of creation. If you don't want interaction with the menu while it's hidden, you can always set those mouse-regions to "disabled" state. But again, it makes much more sense to ONLY create a menu just before it appears on-screen, and destroy it after it's removed from the screen.

The availability function that searches the sector inventory is only called when the box is displayed, so I'm not adding too much overhead to EDB display function.

Its a lot easier to create them when displaying the menu, destroy them when hiding it - otherwise I'd need to keep track of whether the menu was changed somehow - option names changed or an option being no longer available - and update the mouse areas then. It would be more elegant, I know, that's the best I could do given the limited amount of time.

Also, that's how the old popup box system works, or at lest the parts I used as reference. Most of the class is just the militia command box split into more or less logical chunks and fed class variables rather then the old, hardcoded ones.

I'm not even past the point of implementing all of the old popup box functionality in my class, so improvements and optimizations will have to wait. Right now its still a bit of a patchwork of old and new code, but at least it works well enough to be usable.

Ultimately, popup options should be creating their own mouse areas and be aware of their regions on screen, passing them to their callbacks somehow, along with references to themselves and their parent.