I am creating an editor that has a tree view in a text Editor. I have a properties view attached to it so that on selection of each tree item, the properties of the item are displayed. For this each tree item is a class that implements IPropertySource. So the property values are obtained by overriding the methods (like getPropertyDescriptors, getPropertyValue, setPropertyValue and so on) of the IPropertySource class.
The property values are displayed correctly. However, I require the values in properties view to be read-only. Currently, the names are non-editable. But on selecting one of the rows of the property view, the value of that property is editable. How do I make all values of properties of the properties view read-only (non-editable)?
Thanks!
If you are using the standard property sheet page from Eclipse, it depends on the IPropertyDescriptor implementation returned by IPropertySource.getPropertyDescriptors whether and how your property is editable in the view.
If you have a look at the JavaDoc of IPropertyDescriptor, you can see the following:
Clients may implement this interface to provide specialized property
descriptors; however, there are standard implementations declared in this
package that take care of the most common cases:
* PropertyDescriptor - read-only property
* TextPropertyDescriptor - edits with a TextCellEditor
* CheckboxPropertyDescriptor - edits with a CheckboxCellEditor
* ComboBoxPropertyDescriptor - edits with a ComboBoxCellEditor
* ColorPropertyDescriptor - edits with a ColorCellEditor
So for your case returning the PropertyDescriptor should do the trick.
Related
In my application I want to change the editable var at once for 3 nstextfields in a custom NSView. Is it possible to do that using only one line of code (turning something on and of in the NSView perhaps?) or do I have to change it for every object individually? Again all the nstextfields are 'grouped' in one NSView. Hiding the nsview is no option, because it will seem like the entire program is nearly empty.
I have (for example) 3 NSTextFields in a custom NSView and I want to change their edibility option for all of them at once (if that is possible). So that I don't have to do: 'textfield1.editable=false' three times
Use Cocoa Bindings:
Create a dynamic variable editable in the target class
dynamic var editable = true
In Interface Builder bind Editable of each text field to the target class , Model Key Path editable.
Now changing the value of the variable affects all text fields simultaneously.
On my first project trying out Caliburn.Micro, I like a lot of the things :-)
One thing I miss (or havn't discovered yet) is how to separate the viewmodel and a command.
CM doesn't support ICommand, as it's way of doing things is superior. I'm sure it's true, so I would love a small push in the right direction to achieve this or perhaps discover a better way.
As I understand you have to put the "Execute" method and "CanExecute" property directly in the viewmodel, named to match the control in the view, to get the magic to work.
I would like to put the "Execute" and "CanExecute" in a different object that is property on the viewmodel and then CM would automatically bind to that object, using the control name and property names as usually.
Repost from the forum on Caliburn Micro, I didn't get any answers so I'm trying my luck here.
You should try to avoid invalidating the Law of Demeter. Therefore, on your view model you can have an execute method, and a CanExecute property (usually calculated), and these can call into the containing model where appropriate, e.g:
public void Save
{
// .. save logic
}
public bool CanSave
{
get
{
return this.model.CanSave ... and other logic etc.
}
}
You must remember to notify a change in the calculated property when the can save state changes, e.g:
public void CodeThatGetsRunWhenAPropertyOfTheModelChanges()
{
this.NotifyOfPropertyChanged(() => this.CanSave);
}
If you have e.g. a Button on your view with x:Name="Save", then Caliburn.Micro will automatically invoke your Save verb on the view model when the button is clicked, and will automatically enable and disable the button when the CanSave property value changes.
To avoid fat ViewModels you also need to avoid fat Views. Caliburn.Micro allows you to compose Views/ViewModels as described in Screens, Conductors and Composition.
The short version is, you can include a "DetailView" and "DetailViewModel" pair in a "MasterView"/"MasterViewModel" shell by defining a DetailViewModel-typed property in MasterViewModel and adding a ContentControl named after it in MasterView. Binding and actions work as usual, so you avoid both fat models/views and routing of commands.
Another option is to bind a MasterView element to a DetailViewModel property or action, by prepending the detail's property to the target's name. I can't find the specific URL yet, so the example is from memory.
Assuming you have the following classes:
public class MasterViewModel:Screen
{
public property DetailViewModel MyDetails{get;set;}
}
and
public class DetailViewModel:Screen
{
public property string SomeText{get;set;}
public void DoTheBoogie(){}
}
You can add a control in you MasterView named 'MyDetails_SomeText' to bind to the DetailViewModel.SomeText. You can also bind to DoTheBoogie the same way.
I prefer to create a separate View though, named DetailView and add a ContentControl named "MyDetails" in MasterView. This results in a cleaner and more modular design
I have a sample EMF hierarchy like this -
Parent : Shape
Child 1 : Circle
Child 2 : Square
Child 3 : Rect
Now I want to generate my properties view in Eclipse in such a way that . I have a drop down with ShapeType and based on the shape type I want to show the properties of the child element.
Essentially I want to display/edit the child properties based on the 'type' selection in the parent.
Any thoughts how I can achieve this?
You cannot solve this issue easily, as in that case the dropdown needs to change the EMF type of an object, that results in Java class changes. To have such thing working, you have to create a new EObject instance, copy all relevant attributes, and remove the old object (and possibly update the selection).
So, alltogether, I believe, what you want is not possible with basic EMF tooling, however, if you provide a custom model manipulation commands, it should be possible.
Other things, you can try (if possible in your domain):
Move all your data to properties of the parent object, add EValidators to prevent inconsistent states from appearing, and update the default EMF Edit commands to filter out unnecessary editors. Ugly, but may work.
Create custom forms/editors, that manage the object removal/addition during the manually coded editing process.
i have an EObject and want to get all the Properties from it. I tryed to get all Structural Features:
myEObject.eClass().getEAllStructuralFeatures()
but i get too many Properties i do not want like the object ID.
With
myEObject.eClass().getEStructuralFeatures()
there are missing some that are displayed in the Properties View.
So how can i get the same List of Properties from an EObject like the Properties View does?
Thx for your help
Just use the first option and filter out the ones you don't want (like object id) from being displayed. It's probably the easiest way.
If it must absolutely be the same as the list that is displayed in the properties view, the safest bet is to find the code used to populate the properties view and reuse it.
I am currently implementing an Eclipse-Plugin which is using the standard properties view, connected to a Navigator. It also features a textual editor, which is able to connect regions within its' document to certain objects that can supply properties to the PropertiesView (i.e. the same objects, that are displayed in the Navigator).
However, the Tuturials I found only dealt with Views that used a pre-implemented Viewer, which already supported passing on the selected element to the Properties View.
The TextEditor does not do that (I am using jface and a subclass of the AbstractTextEditor class), because it's SelectionProvider returns informations about the offset and the length of the selection only.
How do I have to modify the SelectionProvider of my TextEditor, such that it provides information usable to the Properties View?
Thank you in advance
Okay, I have managed to find the solution myself.
First of all, I had to implement the getAdapter() method in my subclass of TextEditor such that it returns an Adapter for IPropertySourceProvider, that can deal with the type of elements that are selected in my AbstractTextEditor.
Then, I implemented an ISelection that extended TextSelection, in order to not interfere with any selection-specific mechanism supplied by the AbstractTextEditor, and implements the interface IStructuredSelection, because the Properties View works with this interface of ISelection only.
An IStructuredSelection features basic methods of an array, however, in my case it is only possible to ever select only a single element, so implementation of these methods were trivial.
The last step was to get my ISelection to the right place. Overwriting the getSelection()-method of the ISelectionProvider of the AbstractTextEditor did not suffice, because obviously, the methods of firing SelectionChangedEvents does not use this method.
Thus, instead of using a standard SourceViewer, I used my own implementation in which I basically overrid the methods fireSelectionChanged(int offset, int length) and firePostSelectionChanged(int offset, int lenght), such that they use events containing my ISelection.
The rest is implementing the handling of my Objects in the Adapter for IPropertySourceProvider in a way that it returns an IPropertySource for the given Object, as it is shown in various tutorials.