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

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.

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): 

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.

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.