Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Filtered PropertyEditors #28

Closed
vorptronica opened this issue Oct 11, 2014 · 8 comments
Closed

Filtered PropertyEditors #28

vorptronica opened this issue Oct 11, 2014 · 8 comments

Comments

@vorptronica
Copy link

I've been learning a lot about ATF reading the samples but I'm having trouble understanding the roles of contexts and I think they are important to what I'm trying to do now.
I want to view only a subset of my loaded document data in a PropertyEditor.
Starting simply, if I have a category attribute on a set of properties that are being displayed, how would I show only those data items that match a specific category?
I don't want this to be a user-controlled filter; it should be fixed in code. I would like to effectively break my long list of properties into several individual property editors that display only data a single category.
I'm thinking it requires a custom context (or several) that would pre-filter the data but am not certain that's right. Each property editor would require a unique context?
If you could point me to a sample or documentation that could help me I'd appreciate it.
Thanks!
-Len

@vorptronica
Copy link
Author

Ok... I figured out a way to do it but it requires modifying the framework.
I've subclassed PropertyEditor as well as PropertyGridView in order to override the Items getter and do my own filtering. This also required changing the Items getter to virtual and making m_categories, m_activeProperties, and m_propertySorting protected so I could access them from my overridden getter.
Is this the easiest way? Or am I missing a more obvious approach?
Thanks. -Len

@jhshen
Copy link
Contributor

jhshen commented Oct 14, 2014

Hi Len,

By default ATF's PropertyEditor uses SelectionPropertyEditingContext for displaying and editing the properties of the selected object, if there is no client-defined IPropertyEditingContext. See PropertyEditor.GetContext() method. Note SelectionPropertyEditingContext.GetPropertyDescriptors() returns all the visible properties of the selected objects.

Perhaps one approach is to set up your own IPropertyEditingContext, which can be derived or modified from SelectionPropertyEditingContext. Then you can rewrite GetPropertyDescriptors() to expose properties according to your filtering rules.

Does that sounds workable?

Shen

@jhshen
Copy link
Contributor

jhshen commented Oct 14, 2014

Personally I prefer one property editor. If there are multiple property editors, will it be always clear which property editor to look/edit for a specific property?

@vorptronica
Copy link
Author

In my case I have a LOT of properties which, when on a single panel, are quite an eyeful.
I've been looking into SelectionPropertyEditingContext and how to wire a custom subclass into my project. Where is the appropriate place to change from the default context to my SelectionPropertyEditingContext subclass? In Initialize of my PropertyEditor subclass?
Thanks.

@jhshen
Copy link
Contributor

jhshen commented Oct 15, 2014

Inside PropertyEditor.GetContext() method, it calls GetMostRecentContext() to check a client-defined IPropertyEditingContext:

IPropertyEditingContext context = ContextRegistry.GetMostRecentContext();

So if you can set ActiveContext once before the property editor is actually used, like this line

m_contextRegistry.ActiveContext = MyPropertyEditingContext

GetMostRecentContext() call should be able to grab MyPropertyEditingContext.

If you have MyPropertyEditingContext1 & MyPropertyEditingContext2, GetMostRecentContext() will grab the most recent activated one.

@ColinCren
Copy link

It seems like you'll need to have m_defaultContext exposed as protected and not readonly to do what you're looking for. @Ron2 in the past has been great about exposing things for us, perhaps he can weigh in.

@vorptronica
Copy link
Author

I AM able to do what I want by setting PropertyEditor.m_defaultContext to be protected (read/write) with no other changes to ATF.
I'm using a custom SelectionPropertyEditingContext subclass and it's working well.

Ron2 added a commit that referenced this issue Oct 16, 2014
PropertyEditor and GridPropertyEditor: Added the
DefaultPropertyEditingContext property to allow client code to customize
which property descriptors are used for the current selection set in
these two property editors. #28
@Ron2
Copy link
Member

Ron2 commented Oct 16, 2014

Thanks, @vorptronica, for the good suggestion.

I see how it would be useful to customize how the property descriptors are retrieved for the current selection set. I checked in the following addition to PropertyEditor and to the spreadsheet-style GridPropertyEditor:

/// <summary>
/// Gets or sets the default SelectionPropertyEditingContext object. This object
/// is used if there is no IPropertyEditingContext available from the IContextRegistry.
/// Set this to control custom property filtering behavior for the current
/// ISelectionContext, by overriding the SelectionPropertyEditingContext's
/// GetPropertyDescriptors(). Can't be null.</summary>
public SelectionPropertyEditingContext DefaultPropertyEditingContext
{
    get { return m_defaultContext; }
    set { m_defaultContext = value; }
}

@Ron2 Ron2 closed this as completed Oct 16, 2014
Ron2 added a commit that referenced this issue Dec 19, 2014
The Configure() method is now called from Initialize() instead of from
the constructor. This will allow derived classes to use parameters from
their constructors in their override of Configure(). Closes #29.

Added the DefaultPropertyEditingContext property to allow client code to
customize which property descriptors are used for the current selection
set. Closes #28.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

4 participants