Context Menu Status

1 Initial Points encountered during implementation
2 Current Status
3 Screenshots

Initial Points encountered during implementation

For some reason selecting the feature formatters doesn't switch to the appropriate tab, this is the case when selecting the menu item too.
When selecting an already edited class or a cluster, the editor just opens up a new empty tab when chosen from the context menu. When selecting a class in a new tab, the editor defaults to Interface View after loading the text twice.
I'm adding m_show to INTERFACE_NAMES for the english text "Show", this will need translating to the various dialects.
If Context Menu is shown and a menu item is selected, on Windows at least the keyboard then ceases to function. It works fine if the 'Pick' option is used from the context menu. It may be possible that the context menu leaves the editor in an invalid state.
The command structure in Studio would benefit from being reorganized in a uniform way so that commands may be retrieved without having intimate knowledge of the data structures in Studio. This could also benefit a plugin mechanism should we go down that route. It would be nice if we had a generic command registration method that allows a client to register a globally unique command that can be accessed from anywhere and executed in a generic way, much like how COM objects operate.
There is currently no interface for class 'move' refactoring method.
Selection behavior needs to be consistent in Studio editor. If I select text in the Studio editor, then right click over a class, I expect the selected text to be the 'context', not the class. This requires a change in the pebble retrieval mechanism in the editor when contextual pick and drop mode is activated.
I reimplemented the context menu mechanism to allow for Void pebbles (such as when right clicking on the editor background), the original idea of implemented a VOID_STONE object was not feasible as most drop action agents take a STONE object and this would mean placing a veto agent on every drop action to check if the pebble did not conform to VOID_STONE before allowing transport. Now when a Void pebble is passed to the contextual menu agent, I create the default editor menu within {EB_CLICKABLE_EDITOR}.context_menu_handler.
The context menu factory has to be placed in the class where the source is due to the use of plain EV_* objects for the pebble, this means we have no idea of where the source originates from as their is no relationship between PND source and contextual menu handler. This problem was also the reason why the mechanism could not be automated due to no direct relationship between the PND targets and the actual commands without a complete design overhaul.
There perhaps needs to be an m_Breakpoints menu string as I have used 'Debug' for the stoppoints menu, perhaps we could add other things such as 'Run to Feature' or such sub-menu items but for now the 'Debug' submenu is just used for break-points.
There needs to be a set naming convention for class names referring to stone/pebble, stoppoint/breakpoint, and EB_/ES_, personally I prefer the latter for each pair.

Current Status

I've implemented the contextual pick and drop mechanism for EB_CLICKABLE_EDITOR (code not yet committed). I had to change a number of command classes to make them easier to access as although most have a specific type for the command, such as EB_EDITOR_PASTE_COMMAND, there were some commands that were using generic classes, for cut and copy. So I reimplemented these to use inheritance rather that client manipulation of EB_ON_SELECTION_COMMAND