13 Answers, 1 is accepted
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
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
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
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
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
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.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
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.
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