Search This Blog

Wednesday, April 25, 2018

The future of old RichTextPropertyEditor and HtmlPropertyEditor with the introduction of the new Office-inspired Word Processing Module - YOUR FEEDBACK IS NEEDED!!!

Why bothering?
As many of you already heard, we are shipping the Office module with the Rich Text Editor in v18.1. It allows end-users to create, load, change, print, save and convert documents in different formats, including HTML. At this stage, this new module is for WinForms only. We see ways to support more Office functionality and cover other platforms in the future.

As you know, there are two very old XAF Property Editors, which perform similar functions, but with lower quality. They are both based on standard Microsoft controls:
DevExpress.ExpressApp.HtmlPropertyEditor.Win.HtmlPropertyEditor - this is a part of HTML Property Editor Module that integrates the System.Windows.Forms.WebBrowser component. 
DevExpress.ExpressApp.Win.Editors.RichTextPropertyEditor - this is a part of the standard DevExpress.ExpressApp.Win module that integrates the System.Windows.Forms.RichTextBox component.

We created them almost 10 years ago when DevExpress did not provide controls with similar functions. Today, their usage is not justified also because of missing High DPI support, nice icons and useful functions like Mail Merge. Workarounds can be implemented for these standard controls too, but it does not make much sense to invest our resources into this when much better options are already available. These editors have not recently received updates in other areas anyway. This is still a maintenance work for our team that could have been spent on something else.

What we want to change and how?
1. We want to hide the DevExpress.ExpressApp.Win.Editors.RichTextPropertyEditor and its related APIs from Intellisense, the FeatureCenter demo and also from the Model Editor. This is all not to confuse new and existing users. Most Support Center tickets on it are from early days when users could not integrate our RichEditControl on their own with E1509 and the like.
If a string property was decorated with the [EditorAlias(EditorAliases.RichTextPropertyEditor)] attribute and no Office module is added, it will function as before for existing users. If the Office module is added into the app, its new PropertyEditor will be used instead. Since the EditorAliasAttribute feature has been documented only in 2017, the aforementioned declaration had almost zero usage according to our Support Center stats.
If the DevExpress.ExpressApp.Win.Editors.RichTextPropertyEditor was set in PropertyEditorType in the Model Editor, everything will continue to function as before, even with the new Office module plugged in.
If you test Beta v18.1, you may see that our new PropertyEditor is called "RichEditPropertyEditor". We also want to rename it to RichTextPropertyEditor, because we screwed up with the naming. Since the DevExpress.ExpressApp.Win.Editors.RichTextPropertyEditor will be hidden from everywhere, new and existing users should not be confused by the same name.
2. We want to stop recommending DevExpress.ExpressApp.HtmlPropertyEditor.Win.HtmlPropertyEditor for new projects, remove it from demos and mark as "obsolete" in learning materials like we did for Reports Module (Obsolete). Instead, we want to recommend our customers use the new Property Editor from the Office module (it also supports HTML content through the DocumentStorageFormat setting). For instance, in our MainDemo app, you can make this Model Editor setting for the Note class (after Beta v18.1 the full type name will likely change): 

    <Class Name="DevExpress.Persistent.BaseImpl.Note">
        <Member Name="Text" PropertyEditorType="DevExpress.ExpressApp.Office.RichEdit.Win.RichEditPropertyEditor" DocumentStorageFormat="Html" />

If you do not want to migrate to the new editor, you can continue using the former one as you wish -  no problem. Also, it was thus far not critical for our team to think about the removal date at this stage, but we will see how it goes in the future. Anyway, we do not expect any further development to this editor by the reasons I described above. The same notes and procedures apply here as for our Reports (Obsolete) module.

Your feedback is needed!
This plan is NOT YET realized, but I wish to do so by v18.1 release time (in 2-3 weeks). This is the right time to avoid changes when more customers use the new Office module in their projects. If you support this initiative, we will describe the migration path in the Breaking Changes section of our What's New docs, as always. This should help improve user experience for many XAF users and save our team resources.

I'd like to hear from you on what you think about this. Specifically:
Q1: Are you using DevExpress.ExpressApp.Win.Editors.RichTextPropertyEditor and DevExpress.ExpressApp.HtmlPropertyEditor.Win.HtmlPropertyEditor?
Q2: If so, what do you like about them, what problems did you experience so far and how important are they for you?
Q3: What do you think about the proposed changes and the migration path? How would you handle this yourself? Prieb


  1. Hi Dennis,
    The first thing that struck me with the new RichEdit is the long View creation time. A new object just showing an empty RichEdit takes 2+ seconds to show and subsequent viewings average at 350ms. Imagine when a document will be loaded! On the other hand, the classic editor takes on average 22ms to load and only 149ms for first instance. I know these are not equivalent in term of functionality and appearance, but any chance we could keep the new appearance and barebone functionality (I don’t care for mail merge) and improve the instancing speed? Delayed functionality loading :D

    1. Thank you for your feedback. We will take you remark into account and will see how to improve the loading time. Note that you can use standard approaches to decrease this time. For example you can use the ngen tool. Please refer to the A2670 - Why does my code take longer to execute the first time it's run? article to learn more.

    2. @Alex: Our further research shows that a lot of time is spent when creating menu controls. We will see what we can optimize by the release time.
      BTW, if you set MenuManagerType = None not to create the ribbon menu, then opening will be as fast as the classic RichTextBox (1st opening: 1sec, subsequent openings: 140ms).

    3. @Andrey Thanks for the information, I follow and even commented some time ago in the excellent A2670. I've just started testing the new editor and didn't get to jit optimization yet ;)

      @Dennis that's good to know. Perhaps you could create the ribbon group and tabs, but delay the individual button creation when the tab is first activated? A bit like in Xaf TabbedMdi were you open the app with many tabs, but only the visible one is loaded and the others are loaded 'on-demand'.

      I'll keep on testing and give you feedback in my RichEditor ticket.

    4. I will share your ideas with the team, thanks.

  2. We have consistently used the HtmlPropertyEditor in our solutions and I'm looking forward to testing this new editor. The biggest issues we faced with the HtmlPropertyEditor was the lack of spell checking, inability to insert inline images out of the box, and the Save action being enabled immediately after load in some scenarios.

    Renaming the editor and hiding the old editors from intellisense makes sense to me.

    1. Thanks for your feedback, Dave. I hope that the new editor will meet your business needs better.

  3. Hi Dennis,

    we use HtmlPropertyEditor in both xaf's web and win platform for many fields like user formatted descriptions and need display/edit the same content in both platforms simultaneously. It would be great to use your new richtext editor but we cannot use it until it is available for xaf web client too.
    We need your RichText editor's Toolbar mode - the property editor is typically displayed among other properties in xaf's detailView.


    1. Michal, cannot you try our new editor for WinForms and continue using ASPxHtmlPropertyEditor? If not, please clarify why you cannot do this and your requirements in greater detail.