Community
Participate
Working Groups
We are using a recent integration build from early March (03/04). We have an issue where the PropertiesDialogAction is being contributed to objects in the Common Navigator which are not IAdaptable. We need it to either (1) handle non-IAdaptable objects correctly (see example below) or (2) not contribute itself to non-IAdaptable objects. For non-adaptable objects, it could adapt them to the owning IProject/IResource and open the properties on that. We have been using the following to adapt non-IAdaptable objects: public class AdaptabilityUtility { public static Object getAdapter(Object element, Class adapter) { if(element == null) return null; else if(element instanceof IAdaptable) return ((IAdaptable)element).getAdapter(adapter); else return Platform.getAdapterManager().getAdapter(element, adapter); } } We use this whenever when need to adapt an object, and it will handle both Adaptable and non-Adaptable cases.
Not for 3.0
Reopening now that 3.0 has shipped
The PropertiesDialogAction is added for any type that has a property page associated with it. If it is adaptable the adaptable value is checked as well. If this is not the behaviour you see please reopen this bug but we do not intend to change this algorithm.
The action will fail if applied to any EMF objects. We would like to use the Property Pages associated with the underlying resource (or IProject) associated with an EMF model object. We found that it automatically assumes the object in the selection implements IAdaptable. This is not always the case (e.g. EMF objects). We added an Eclipse (Not EMF) AdapterFactory which can adapt the EMF model objects to resources and projects, but the PropertiesDialogAction does not give them a chance to use it. The code supplied below handles the case where you're dealing with an IAdaptable object, and the case where you are not. We had to copy code down to change this functionality, we would like to take this out when we pick up the next release.
Can you show me the markup that fails in your plugin.xml please? i.e. are you specifying a type for the properties page and the check fails? Or are you trying to apply a page that belongs to a resource your EMF object does not adapt to. When you say associated you mean that the EMF object is adaptable? I need a concrete example to see where the issue is. Here is the code in ObjectContributionManager that is getting these contributions - what is not working for you here? Class objectClass = object.getClass(); Object adapted = getAdaptedResource(object); if (adapted == null) return getContributors(objectClass); else return getContributors(objectClass, adapted.getClass());
*** Bug 78552 has been marked as a duplicate of this bug. ***
*** Bug 74891 has been marked as a duplicate of this bug. ***
*** Bug 37084 has been marked as a duplicate of this bug. ***
Created attachment 16394 [details] patch to allow non-IAdaptables to have property pages
Tod, It's quite simple really - look at IWorkbenchPropertyPage and PropertyDialogAction. They assume the selection is IAdaptable and this is what people are complaining about. There is never a need to make such an assumption, so I've contributed a patch to fix this. The patch is backwards compatible by wrapping the selection into an IAdaptable Forwarder so that IWorkbenchPropertyPage doesn't have to change. Another option could be to add another propertypage interface, but that seemed like overkill.
As we now have a fix upping priority.
Would it be possible to apply this in M5?
Assuming this patch is fine I see no reason why not.
Tod, are you going to put this into M5?
If we get time - if not it will go in at the beginning of M6
*** Bug 81011 has been marked as a duplicate of this bug. ***
*** This bug has been marked as a duplicate of 92601 ***
I've seen a few requests for this on the newsgroup lately. I think we should consider putting this in if it's not overly complicated (as comment 10 seems to indicate).
