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

Office-Inspired Products
08 September 2019

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.

6 comment(s)
Patrick Miller
Patrick Miller

In my app, I allow the users to set the default font, size and color for the richtexteditor - With the new update, I will no long be able to do this? They will be forced to use the what ever theme is being used? A little confusing for me.


This is the code I use now. "Winforms"

RichEditControlCompatibility.DefaultFontName = FntName

RichEditControlCompatibility.DefaultFontSize = FntSize

RichText.Document.DefaultCharacterProperties.ForeColor = ColorTranslator.FromHtml(FntColor)


Pat


9 September, 2019
Damon (DevExpress)
Damon (DevExpress)

@Patrick

The breaking change will not affect the DefaultFontSize and DefaultCharacterProperties properties.

The only property affected is DefaultFontName.

You have two options to keep the current behavior:

  1. You can set the RichEditControlCompatibility.UseThemeFonts static property to false when starting the application so that it affects all instances of the Rich Edit Control.
  2. You can set the UseThemeFonts property to false before loading a new document into the Rich Text Control as follows:
RichText.Options.Behavior.UseThemeFonts = false;
10 September, 2019
Patrick Miller
Patrick Miller

Thanks Damon for info, So If I disable the "UseThemeFonts" by setting it to false, I then will still be able to use the DefaultFontName property to set the default font before a new document is loaded? 

Pat


10 September, 2019
Damon (DevExpress)
Damon (DevExpress)

@Patrick

Yes, you are right, this setting is enough. Please feel free to contact us if you need any further information.

10 September, 2019
Vladislav Kiselev
Vladislav Kiselev

What these themes are?

Is theme a set of document styles?

Will it be possible to declare typical theme somewhere in code and then apply it to all newly, programmatically created documents using API?

16 September, 2019
Damon (DevExpress)
Damon (DevExpress)

@Vladislav

A document theme is a set of formatting choices applied to the whole document. It is a part of a document, and it includes theme fonts, colors, and effects, which are applied to the entire content of the document.

We’ll provide theme fonts' support in v19.2.

The document theme contains two sets of font names for the heading and body text fonts. Each set includes font names for different languages used in the document. When the document is created, it uses the default theme, but you can apply your theme just after creating a document in code using an API.

17 September, 2019

Please login or register to post comments.