I think the real problem is that that ACTIVE macros are used at all. In the past I think Ted had also expressed a desire to remove SP_ACTIVE_DESKTOP and its friends. I definitely feel that way.

One problem is that you break encapsulation. A component or widget being used says "hey, I know who should be calling my from up higher, so I'll peek out and find him".  Among all the other problems, this also makes things hard to use. You might pass in a few parameters, but without inspecting the code it is hard to see what the bit will use or go looking for.

Another problem is that this hardcodes the assumption that the thing is a singleton being used for all desktops. This is exactly the sort of thing that started getting in the way of the dockable dialogs. A floating dialog version of a panel still should operate on the "active" desktop's document, however all embedded ones should work on one and only one desktop (the one it is embedded in). At the moment this problem can be worked around by setting the active desktop for those as active is changed, but you might get race conditions (like might be the bug here), and you can also see things like docked dialogs showing info on windows they are not actually docked in.

As Ted pointed out a while back, verbs have the desktop they are called from as a parameter... so that should be passed on down and no SP_ACTIVE_DESKTOP, IS_ACTIVE, etc, should be called. As functions call sub-functions, instead of the desktop they can pass on in things like the document, an object, etc. Limiting the type to the "smallest" and most atomic needed.

So instead of having code "poll" to find out what the active thing of the moment is, things should have the change in active desktop "pushed" down into them. You might ask "what about the floating dialogs?". That is simple. The *dialog* holding the panel should be the one watching for "active" changes, and pushing that down into the panel as it goes.

One additional refinement is that I think we need to get some "contexts" that contain some data and an interface to get at that data. At the moment we have "the whole big application", "the whole editing window" and "the whole document". I'd like to see some that are broken down to a finer degree. In fact, with the tablet support I've got need of that already. As you switch what device you use on the tablet, we switch tools. It would be nice to have a clean, generic way to also switch in a subset of settings. That way the tip of the pen could be the calligraphy tool set for drawing, and the back could be the same tool but set for engraving, etc.