Community
Participate
Working Groups
The Default implementation of the Properties is pretty rigid. I would like to have it extensible and allow users to override the implementation of PropertySheetPage. A Use case would be, if I want to create a Property view, to display more information of a specific selected part of the Java Content Outline, than the content that it shows me by default (Which is just the name of the component), I can do so. By design the Property View is pretty rich in its ability to display different a fairly complex tree structure. Most of the classes (Event generators/Listners etc) in the package are visible only within the org.eclipse.ui.views.properties package. This makes it virtually impossible if I want to override the call to getAdapters (IPropertySource.class) from the selectionChanged() method in the PropertySheetPage. - PropertySheetViewer (Package level visible class) - PropertySheetCategory (Package level visible class) - PropertySheetAction (Package level visible class) - IPropertiesHelpContextIds (Package level visible class) - PropertiesMessages (Package level visible class) - ICellEditorActivationListener (Package level visible class) - FilterAction (Package level visible class) - DefaultsAction (Package level visible class) - CopyPropertyAction (Package level visible class) - CategoriesAction (Package level visible class) However, I am not sure if what I am requesting is already available in some form.
There was some extra API opened up here in 3.1. See bug 24694. However, the types you mention ar still package-visible, and more work would be required to support your scenario. Not only would the properties view need to be opened up more, but you would need to be able to intercept the request from the properties view to the Java editor for its outline page, and provide your own. The Java outline itself would also need to ensure it was subclassable. To make the scenario more concrete, can you describe the kind of extra info do you want to show?
*** Bug 99726 has been marked as a duplicate of this bug. ***
What I'm looking for is the ability to edit complex properties on a wizard page. There is no view, and there is no need for event propagation on model change because the wizard is modal with respect to the model.
Hi Nick, Sorry for the delay in getting this accross. We need to display annotation information from the Compilation Unit editor, on the property view. So if the user clicks on @Jpf.Action {name = "index.html} We should be showing the Action annotation node, with "name" as an child attribute, having value index.html. This information is available to us from the underlying AST tree. Now, the Compilation Unit Editor, currently passes the method name to the property view, which largely ignores this. If I wish to over ride this functionality it is not possible in a simple manner. To achieve this, I currently need to hook into the PropertySheetPage class, and ignore the PropertySource data passed from the CompilationUnitEditor as follows: public void selectionChanged(IWorkbenchPart part, ISelection selection) { if (viewer == null) return; // Modified default implementation of Property Sheet if (part instanceof CompilationUnitEditor) { AnnotationPropertyDriver driver = new AnnotationPropertyDriver((CompilationUnitEditor)part, selection); Object [] adaptables = {driver.getPropertySource ()}; /* Here I get the Annotation information from the part which is a compilation unit editor, parse the annotation nodes, generate a set of Property descriptors for them, and return a handle to this implementation of IPropertySource */ viewer.setInput(adaptables); return; } // change the viewer input since the workbench selection has changed. if (selection instanceof IStructuredSelection) { viewer.setInput(((IStructuredSelection) selection).toArray()); } } - Rajeev
I'm using eclipse 3.2M4. I want the properties view to publish information on what property has been selected in the properties view (My requirement is to show related info on the selected property in another view) The method org.eclipse.ui.views.properties.PropertySheetViewer#fireCellEditorActivated(CellEditor activatedCellEditor) would enable me to do the same. The problem is that the class and many more classes in this package have package level visibility. This has been correctly mentioned in duplicate bug (https://bugs.eclipse.org/bugs/show_bug.cgi?id=99726)
Reassigning bugs in component areas that are changing ownership.
This bug hasn't had any activity in quite some time. Maybe the problem got resolved, was a duplicate of something else, or became less pressing for some reason - or maybe it's still relevant but just hasn't been looked at yet. If you have further information on the current state of the bug, please add it and remove the stalebug whiteboard tag. The information can be, for example, that the problem still occurs, that you still want the feature, that more information is needed, or that the bug is (for whatever reason) no longer relevant. --
