Prepared Editor Event Doesn't Fire

[Brad]

In my last post (http://www.telerik.com/forums/missing-eventargs-type) I couldn't get this event to fire without error.  After upgrading to version 2016.3.1024.45, I can't get it to fire at all.  Using the sample solution Validation_WPF, I just added a handler for the event; no joy.  I'm don't know whether you must have a custom property editor, but I do have one in my real solution, still no joy there.

[Stefan]

Hello Brad,

In order to be able to use the PreparedEditor event, you need to set the EditMode of RadPropertyGrid to Single. Can you please give the approach a try?

We will also update our documentation accordingly, so that such misunderstandings are avoided in the future.

Regards,
Stefan X1
Telerik by Progress

[Brad]

EditMode single can only be set along with RenderMode flat (exception raised).  Ugh, with render mode flat no custom editors appear until you click inside the property grid cell.  That won't work; users need to see the controls.  Anything I can do about this?

[Stefan]

Hi Brad,

Indeed, as documented in the article to which I referred, the Single EditMode can be set only with Flat RenderMode. As to the behavior you described, it would be the expected one. The editor of the control is loaded on demand when the user is about to enter edit mode. Thus, the PreparedEditor is raised when you click inside the field. Am I missing something here? May I ask you to share some details on what would be the behavior that you are expecting?

Best Regards,
Stefan X1
Telerik by Progress

[Brad]

I simply need the PreparedEditor event regardless.  I need to set properties on the control used to set the property depending on what kind of overall item is selected.  This is completely irrespective of RenderMode (which can't be flat since users need to see something or they won't bother clicking in the grid cell in the first place).

[Stefan]

Hi Brad,

Generally speaking, setting the RenderMode property to Flat will not make any visual difference to the end user. This property is meant to be used for setting the mechanism through which the control renders its items. This is documented in the Layout Render Mode article. So, may I ask you to clarify, what is the element that the users are not able to see when the RenderMode is set to Flat?

Regards,
Stefan X1
Telerik by Progress

[Brad]

My custom control that appears in the grid cell.  It doesn't appear unless you have focus in that cell.  At all other times the cell appears empty.  Actually, there is also nothing in the cell when the property is an enumeration, but that's another problem - enumerations just flat aren't working in my project.  They work in a sample, but not in my real project.

[Stefan]

Hi Brad,

This behavior would not be the expected one. Can you please check out the Combobox editor for Boolean property SDK Example? As demonstrated in it, the custom editor is visible  when the RenderMode of RadPropertyGrid is set to Flat. The example can be reviewed also through the SDK Samples Browser.

So, may I also ask you to check whether there are binding errors in your application? They can be observed in the output window of Visual Studio when running the project in debug mode.

Regards,
Stefan X1
Telerik by Progress

[Brad]

In that sample, RenderMode flat is fine.  Add EditMode single (like we've discussed) and you can't tell what kind of control it is.  With my control, you can't see anything.  No binding errors.

[Stefan]

Hello Brad,

Thank you for this clarification.

Indeed. this is the default behavior of the Single EditMode. It uses TextBlocks when the control is in view mode and as already mentioned in one of my previous replies, loads the editor on demand. With this in mind, using the PreparedEditor event without setting the EditMode to Single interferes with the by-design behavior of the control. May I kindly ask you to share your initial intention to use the PreparedEditor event? What logic are you planning to base on it?

Regards,
Stefan X1
Telerik by Progress

[Brad]

Now we're going in circles.  I've already answered this.  Pasting in text from a few posts up:

I simply need the PreparedEditor event regardless.  I need to set properties on my control used to set the property depending on what kind of overall item is selected.  This is completely irrespective of RenderMode/EditMode.

The issue is: I need the event and being able to use the event should no relation to visual/stylistic properties.

[Stefan]

Hello Brad,

Please excuse me for overlooking this.

Though I am not completely aware of the setup at your end, I would suggest you a slightly different approach for achieving your goal. As you mentioned that your logic needs to be processed irrelevant to the EditMode/RenderMode of RadPropertyGrid, relying on the PreparedEditor would not be the best choice. As I am understanding from your description, you need to use the event to synchronize the data manipulated by RadPropertyGrid with some properties of your custom user control. A cleaner approach for such requirement would be to use your view model and synchronize your data through data binding. Are there any obstacles to adopting such an approach?

Regards,
Stefan X1
Telerik by Progress

[Brad]

Well, I've had to move forward (lest I be fired).  I am doing standard binding, but the issue is, without the event (or the xaml way I describe below) I have *no tie between my control and my view model*

So the choice is this:

* Capture the event, when my control is present, set some properties.

* Create a DataTemplateSelector for the property grid.  Set up mounds of xaml, add a code file with the logic for the template selector, monkey with xaml for hours/days.  Don't forget the magic "AutoBindBehavior.UpdateBindingOnElementLoaded" binding.

Normally doing things declaratively is preferred, but concerning xaml; setting things in code is straight forward, data templates complicate things by an order of magnitude.  The next person who comes along will spend half a day trying to figure out how in the world this thing works.  If it was a matter of code in the event, it would be *vastly* easier.

[Stefan]

Hello Brad,

Thank you for the update.

I do understand that using the event would require significantly less effort. I am afraid, however, that this is the by design implementation of the control. It is not meant to serve all use cases and we cannot commit ourselves to modifying it. So, I suggest you sticking to the solution you've already found.

Best Regards,
Stefan X1
Telerik by Progress