- Add color code for uneditable annotations values
  - light gray: annotation does not exist for the given model elemnt
  - light blue: annotation is a derived / computed value
refs 1841

  Simply label it "Model Element"
- Likewise, in component filter, use "model element" instead of "component" as filter label
refs 1841

- In contrast to the implementation of EObjectAwareServiceBase.getRegisteredHandlers(Class), this implementation returns all IAnnotationValueProviders that have
been registered for the given class or any of its super-classes or interfaces.

- As a result, value providers may now be bound to different base classes of a given model element, e.g. for GenericECU, annotations that have been bound to ExecutionUnit and IPlatformArchitectureElement will be return (old behavior: only annotations bound to the nearest match, i.e. ExecutionUnit, would have been returned).

- TODO: Investigate if this behavior is also (optionally) desirable for other services and should be merged / integrated to EObjectAwareServiceBase.
refs 1841

refs 1841

refs 1841

- Add GenericAnnotationView.setFixedAnnotationFilter(). It can be used to install an externally created filter instead of the filter option GUI. This can be used to embed GenericAnnotationView in another widget, and to restrict its scope accordingly.
refs 1841

- Split filtering functionality and filter option widget:
  preparation to configure view with fixed filter (and to hide the filter option UI), e.g.
  for embedding the view in another UI control.
- Merge column filtering methods into (row) ViewerFilter
refs 1841

 - Do not add grid layout data that determines how the new ExtendedCCombo is added to its enclosing layout and do not set options in the constructor. Both violate the encapsulation and complicate the reuse of ExtendedCCombo in different contexts.
 - Override all add*() and remove() to ensure consistency of underlying CCombo and list of referenced objects.

  - ExtendedCCombo -> CCombo whose entries are linked with foreign data

- Fix warnings by removing reference to getTextPostConvertValidator() in class comment. Method has been removed in r10818.

- GenericAnnotationView: Enable to restrict view to currently selected element type (e.g., components, channels, ...)
- AnnotationViewPartBase: Generalize selectionChanged() to handle all graphical model elements (required for the above feature)
refs 1841

refs 1841

- Fix editing of dynamically instantiated annotations
refs 1841

  - Get factory from EStructuralFeature types
  - Get default values from meta-model
  - Remove EStructuralFeatureDescriptor
  - Enable automatic construction of a EStructuralFeatureValueProviderBase for all features of a given EClass (instance key = field name)
- Unify creation of editing support
  - Merge Enum support into EStructuralFeatureValueProviderBase
  - Enable management of input selectable from ComboBox also in the multi-instance case
refs 1841

- Enable binding a AnnotationValueProvider to multiple model elements in a single <annotationViewPart /> statement
refs 1841

refs 2119

- EStructuralFeatureValueProviderBase: Gracefully handle the case that instance keys returned by getInstanceKeys() are not backed by a EStructuralFeatureValue
- Concrete value providers may use this to implement an overlay of e.g. derived/computed annotations onto a concrete IAnnotationSpecification that consists of one or more EAttributes
refs 1841

- Ensure that independently of the currently selected model element type, annotations are shown for the entire sub-model below the IProjectRoot element above that currently selected model element. E.g., in the LA, show annotations for Channels in case a Component is currently selected
refs 1841

- Fix typo in GUI label
- Formatting of comments
refs 1841

- SingleEStructuralFeatureValueProvider -> EStructuralFeatureValueProvider (can optionally handle multiple EStructuralFeatures contained in a specification)

- TODO: Mixing the edit support (ComboBox, Text) and the EStructuralFeature type (enum vs. other primitive data types) is not possible)
refs 1841

  - Enable selection of values for non-enum attributes from a combo box. The following options are available:
    - Fix set of values
    - Dynamically managed set of values. The user may either choose from the existing values for a given annotation type, or enter a new one. Deleting existing choices is also supported.
  
- AnnotationViewPartBase: Also watch specifications in order to ensure update of admissible choices (see code for detailed comments)

- GenericAnnotationView: Set viewer input before construction of columns in order to enable aggregation of admissible values
refs 1841

refs 1841

refs 1841

- Add comparator that sorts rows according to hierarchy level. Elements within one hierarchy level are sorted by name.
refs 1841

- Ignore update requests for elements that are not hook to a top-level element,
e.g. SET events that are fired when a component is removed (before the actual REMOVE event).
- Otherwise, the AnnotationValueService would create an NPE during the preparation of the context via KernelModelElementUtils.runAsCommand()
refs 1841

refs 1841

refs 1841

- Optimize drawing speed by disabling the redraw while the new set of columns is beeing created

- Ensure that "Create" columns for dynamic multi-instance annotations are right to the corresponding instances.
- Simplify column handling. Merge updateSingleInstanceAnnotationColumns() / updateMultiInstanceAnnotationColumns() into update()
refs 1841

 - allowsMultipleAnnotationInstances() -> allowsDynamicAnnotationInstances()
 - add getInstanceKeys()
- MultiInstanceValueProviderBase -> DynamicInstanceValueProviderBase
- Concrete IValueProviders may now either support the dynamic creation of instances (using the EMap based implementation provided by DynamicInstanceValueProviderBase)
- Alternatively, IValueProviders may statically support a number of "views" onto an annotation by returning the supported instance keys in getInstanceKeys() and implementing the required case distinction in get/setAnnotationValue() and createEditingSupport()
refs 1841

 - Change return type of getValue() to T
 - This allows for more type safe implementation of the underlying calculations
 - The former abstract base class DerivedAnnotationBase used Object as a return type for getValue() to due an EMF code generation bug for generics if the base class is located in a different .ecore file than the concrete class. For interfaces, this bug is not triggered.
  
refs 1841

Introduce "derived" annotation, i.e. based on calculations instead of explicit annotations / model contents can be implemented

- DerivedAnnotationBase meta-model element, with getValue() EOperation, and a extensive documentation.
- Corresponding DerivedAnnotationValueProviderBase, implementing a read-only, text-view of the calculation result
- To implement the above, move handling of annotation EClass & factory to ValueProviderBase

refs 1841

- Fix NPE in case a filter actually strikes

 - renamings of model elements (e.g., in the properties view)
 - addition of new instances of multi-instance annotations

-> Use originator of the notification, and not the new value to trigger the update
refs 1841

refs 1841

- Move column label provider displaying the model element names in the first column to a dedicated class ElementNameLabelProvider
- Introduce IAnnotationViewPart

- Ensure and document that all output of TextEditingSupport.getValue() is converted to a non-null String. This is required because this value will be consumed in TextCellEditor.doSetValue() which expects such input

- Apply <underlying EMF Factory>.createFromString() to all String input in order to ensure conversion for input received e.g. from TextCellEditors on all code paths