Custom Editor Factory

We are considering your PG as a replacment of our homebrew control

Ouer framework allows editors to have constructors with parameters

As far as i understand editors in your PG are instantiated with parameterless constructor  

Is there a way to overcome this ?

An editor in our grid is a DataTemplate.  (Strictly speaking, an editor is an object which associates nodes with a specific DataTemplate, but that's probably not important.)  Therefore, anything you can express in XAML plus code-behind, you can use in an editor.

XAML can indeed only create types with parameterless constructors, but you can work around this using code-behind.

For example, define a new UserControl type.  In its constructor, create an instance of your class using the parameterised constructor.  Set the user control's Content to this instance.  The trouble is that, depending on where they come from, you may still have an issue with passing parameters to the constructor: if you want to pass them in as control properties, those don't get set until after the constructor has run.  You can get around this using the Loaded event or EndInit method.  Then your editor DataTemplate consists of an instance of this user control.

You might also want to review whether your existing WPF components can be refactored to support parameterless construction; this may seem like more effort/risk, but may have a greater payoff in terms of making the controls more reusable and XAML-friendly for other projects.  Just an option to consider.

I can probably give you more specific guidance if you tell me a bit more about your existing framework -- how do you currently implement editors and what sort of parameters do you need to pass to them, and are these parameters essentially static (e.g. connection strings) or do they need to vary from instance to instance?  Could you give us an example?

Parameters passed to constructors are not static for example they might represent context specific items in curently opened document. Any way, components are constructed  automaticaly as in IoC frameworks. In genral our automatic object construction serves same purpose as IServiceProvider.GetService in standart System.Component namespace. Except that we striclty require for component to declare any needed service in constrcuctor parameter

Your suggestion with custom control will not work becouse he does not have ways to get contextitems\services except declaring constructor with parameters and violate Xaml requrement.

All we need is having PG expose assignably custom factory callback property  somthing like

delegate object CreateInstance(Type objectType)

Making our components XAML friendly is meaningless becourse they are too specific. And not having context info assigned for them makes them useless.

Thanks for that clarification.  The property grid expects editors to be packaged up as DataTemplates.  The WPF infrastructure will then instantiate that DataTemplate.  Because WPF is doing the instantiation, we cannot control the instantiation of the template or the construction of controls within it.  So we cannot provide a factory hook for constructing controls within editors.

(We can and do provide a factory hook for creating the DataTemplates themselves.  But I don't think that will meet your requirements, if I've understood the nature of your components correctly.)

I still think a custom control is our best bet for getting this to work.  You say that a custom control would "not have ways to get context items/services," but your proposed callback signature implies that you would not need the property grid to supply the context items/services.  Where do the constructor parameters come from?  Are they supplied by the IoC container, or by an application/window context?  If it were possible (absent the DataTemplate issue) for the grid to instantiate the "inner" control using a factory method, it should be possible for a custom control to do the same.

For example, suppose we create a control called ContextualControlHost, which derives from ContentControl.  We add a new dependency property of type Type, named HostedControlType.  In the PropertyChangedCallback for HostedControlType, we run your factory method, and set ContextualControlHost.Content to be the control returned by that factory method.

If the constructor parameters are coming from somewhere other than context, you could pass them to ContextualControlHost via properties, and defer running the factory method until EndInit, when both the type and the parameter properties would be available.

You would then be able to use ContextualControlHost in a DataTemplate, because CCH has a parameterless constructor, but CCH would just be a shell around the "real" component which would have been instantiated using the factory.  CCH would be able to wrap any of your components, so creating CCH would be a one-off cost (and would be pretty simple, so not a very big cost).

Does that sound like it would meet your requirements?  It introduces a bit more "noise" than having a factory method on the grid itself, but the WPF DataTemplate architecture simply does not allow us to offer the latter solution.

Thank you for thorough explanation. We will consider you solution