Community
Participate
Working Groups
I was walking through some code that sought to respond to changes to the MApplication's menu contributions (formed from the 3.x <menuContributions> stanzas). My event listener was getting a strange event whose type was "UNKNOWN". It turns out that adding the generated MMenuContributions to the app instance (in MenuPersistence#read()) causes an EMF ADD_MANY notification, which we don't interpret properly in UIEventPublisher#getEventType(). We instead map the notification to event type "UNKNOWN", which has the effect that the old and new values are never set in the event properties. I'm not sure what we should be mapping this ADD_MANY to.
We should also see if we can adjust to handling the EMF 'move' semantic (where you don't do an explicit 'remove' from the current parent, you just do an 'add' to the new one. There is a way to detect that this is the case in the event but I've forgotten what it is...
Brian, would you be able to look at this in 4.2.1? PW
Sure
Created attachment 217822 [details] patch v1 This patch adds support for three new event types to UIEvents.EventTypes (ADD_MANY, REMOVE_MANY, and MOVE) correspond to EMF's notification types. It also adds a new event property to (UIEvents.EventTags.POSITION) to record where operations took place (primarily for MOVE, but also useful for REMOVE and REMOVE_MANY). Unlike ADD and REMOVE, ADD_MANY and REMOVE_MANY report collections of the added/removed objects. In changing existing code to handle both ADD/ADD_MANY and REMOVE/REMOVE_MANY, I ended up adding two helper functions to UIEvents: * contains(Event e, String propName, Object o): check if a property contained a particular value (e.g., in MinMaxAddon: to check if new tags contains "Minimized" on ADD_MANY) * asIterable(Event e, String propName): return an iterator over the property regardless of whether a single instance or a collection (e.g., for PartRenderingEngine to iterate over multiple elements in an ADD_MANY) I haven't adapted any code to make use of MOVE -- that should be done separately, IMHO.
Fix committed to master (24bfc76ae59a0a8b47f7fde56797921723f6f994)
*** Bug 317419 has been marked as a duplicate of this bug. ***
Verified in M20120829-1200
