Word Processing (WinForms, WPF, Office File API) - Breaking Changes (v19.2)

In this post, we’ll discuss two important changes to our Word Processing product line (v19.2). These changes may affect your v19.2 upgrade path. Please review this document carefully.

Theme Fonts

Based on feedback, we included document theme support in our 2019 word processing roadmap. To help deliver this functionality, we’ve been forced to change how we select the default document font. In previous versions, you could control the default document font via our DefaultFontName static property. With v19.2, our Rich Edit Control (WinForms and WPF) and Word Processing Document API will use document themes to retrieve default document font information. As such, the DefaultFontName property will no longer affect the default document font.

We understand that this represents a substantial change. To reduce its impact as much as possible, we’ve introduced two properties to disable document themes:

1. A static property to disable themes for all components within your application.
2. A property that allows you to disable themes in specific instances (for both our Rich Edit control and RichEditDocumentServer).

To make certain that this solution addresses your business needs, please take a moment to answer the following question:

Adjacent Tables

We’ve received a number of reports regarding an issue that occurs when adjacent tables (created in code) are exported to the DOCX format.

This issue does not occur when users create tables via the user interface. When creating adjacent tables via the UI, our Rich Edit Controls (WinForms and WPF) combine adjacent tables like Microsoft Word.

The following image helps describe the issue (when creating adjacent tables in code) in greater detail:

The following code snippet reproduces the issue outlined above:

DevExpress.XtraRichEdit.API.Native.Document doc = richEditControl1.Document;  
doc.Tables.Create(doc.Range.End, 1, 3, 
                  DevExpress.XtraRichEdit.API.Native.AutoFitBehaviorType.AutoFitToWindow);  
doc.Tables.Create(doc.Range.End, 3, 5, 
                  DevExpress.XtraRichEdit.API.Native.AutoFitBehaviorType.AutoFitToWindow);  

doc.SaveDocument("123456.docx", DocumentFormat.OpenXml);  
doc.SaveDocument("123456.rtf", DocumentFormat.Rtf);

The cause of this issue lies with Microsoft Word. It interprets two adjacent tables as invalid and combines these tables into one just after document load - regardless of document format. The problem of course is that the resulting table’s layout is format-specific.

We’ve modified our TableCollection.Create method to address this issue. If you create a new table prior to or after an existing table, this method automatically combines both tables.

To restore the previous behavior, simply set the MergeSuccessiveTable property to false (this will keep successive tables separate from one another):

DevExpress.XtraRichEdit.RichEditControlCompatibility.MergeSuccessiveTables = false;

Should you have any questions regarding these changes, feel free to comment below or submit it a support ticket via the DevExpress Support Center.