Disclaimer: The information provided on DevExpress.com and affiliated web properties (including the DevExpress Support Center) is provided "as is" without warranty of any kind. Developer Express Inc disclaims all warranties, either express or implied, including the warranties of merchantability and fitness for a particular purpose. Please refer to the DevExpress.com Website Terms of Use for more information in this regard.
Confidential Information: Developer Express Inc does not wish to receive, will not act to procure, nor will it solicit, confidential or proprietary materials and information from you through the DevExpress Support Center or its web properties. Any and all materials or information divulged during chats, email communications, online discussions, Support Center tickets, or made available to Developer Express Inc in any manner will be deemed NOT to be confidential by Developer Express Inc. Please refer to the DevExpress.com Website Terms of Use for more information in this regard.
Hi,
are there any news about this bug?
we need this functionality as soon as possible!
thank you very much
Hi Tobias,
I'm afraid currently I don't have any news. Our developers are working on this issue. When we get any results, we will notify you of this in this ticket.
Thanks
Alex
Hi,
to when we can expect a solution for this issue ?
Just installed 14.1
Hello,
Our developers are still working on this issue. I am afraid at the moment I can't provide you with exact time frames as to when this issue will be resolved.
But we will do our best to implement it as soon as possible.
We will keep you informed of our progress.
Hello,
since my first entry are 4 weeks elapsed. do you have any news about this issue?
thank you very much
Hello Tobias,
In fact, we need to implement this functionality in WPF from scratch, so this requires time. We're working on this feature and if everything goes according to plan, it will be finished in a couple of months.
Does this mean we'll also have to wait for a couple of months for this functionality in WinForms?
No, this feature is already available in the WinForms version of RichEdit. This issue is related to the WPF version only.
Ted,
Ah ok, thanks.
We nee this feature too. Please fix asap.
Any chance this being hotfixed in v13.2.5.0?
Please note that the AutoSizeMode property is related to the feature implemented in the context of the Add the capability to resize control based on own content size ticket. This feature was implemented in the 14.1.3 version of the RichEdit control. So, this issue will be resolve in the 14 version.
I am waiting for this feature to be implemented also. Thanks in advance for fixing it.
So how far along are you guys with realizing this functionality for WPF? We are getting to a point where we have to decide to use another control than DevExpress's RichEdit. A choice I really would hate to make.
Hello Danny,
I am concerned to hear that you are going to use another control in your application. At the same time, I can understand your decision since the absence of the AutoSize feature in our WPF RichEditControl is a showstopper in your further development.
The matter is that our initial attempts to implement this feature in the WPF version of the RichEditControl component were unsuccessful. We faced several difficulties while researching the possibility of implementing this feature. It turns out that we need to significantly re-design our internal WPF RichEditControl structure to support this feature. That is why we were not able to fix it quickly.
Please note that this ticket has the highest priority. Our developers will continue working on implementing the "AutoSize" feature in WPF RichEditControl.
To my regret, I can't provide you with exact time frames as to when this issue will be resolved. We will update the status of this ticket once we have any results.
Hi Oleg,
We have raised this issue 4 years ago for Silverlight and the ticket No is Q319097. Now we are using 14.1.6 still AutoResize feature is not working. Could you please guide us in resolving this issue.
Thanks,
Ari.
Yes Ari,
I saw this ticket. As you know in version 14.1.3, we introduced the AutoSizeMode property only for the WinForms version of RichEditControl and only for a simple view.
No doubt, this feature should be also provided for the WPF version (the next step SL) of RichEditControl. However, as I previously mentioned, while implementing this feature for the WPF version we faced several difficulties caused by the WPF architecture. We need to significantly re-design our internal WPF RichEditControl structure to support this feature.
This is a difficult task and we have not yet finished our work on supporting this feature in WPF. Although I cannot provide you with exact time frames as to when this issue will be resolved, I can say that we are keenly aware of how needed it is.
Once it is implemented, we will update the status of this ticket.
Hi Oleg,
While your team is implementing this feature, is there a workaround that you can provide to resolve this issue.
Thanks,
Ari.
Hello Ari,
To my regret, I can't suggest any suitable workaround to support the "Auto Size" feature in WPF RichEditControl using the current architecture of this control.
Our developers are working on this feature, but as I previously mentioned, the implementation of this feature turned out to be more complex than we initially thought.
Nevertheless, I would like to note that the priority of this ticket is high, and we will update its status once we have any results.
Hi DevExpress,
Considering 15.1 is around the corner… I just wondered if you had any more information on this?
I moved to DX years ago because you guys were the only ones to offer a rich text editor which we badly needed. It turns out yours wasn't really designed to be used like other "simple editor" controls and our customers have been having to live with a rather crude hacky solution for the last 4 years (when I first raised our concern… https://www.devexpress.com/Support/Center/Question/Details/B220659). We constantly get calls to support regarding this.
I appreciate the fact the WPF control needs major changes to work in the desired way. What's the current status though… are you currently in the process of re-writing the control still? Or have you essentially put the existing one to one side (as it's good if you want to write a replacement for MS word!)… but are working on a brand new "lighter weight" version, designed to be used multiple times in a form, with auto-sizing, like normal text boxes?
It'd be great if you did want to let us know there's a good possibility of it being included in the next release! But I'm guessing it'll be the standard "can't provide you with exact timeframes"… but can you confirm this is still being worked on? Any idea at all whether it'll see the light of day this year… or maybe next?
I completely understand you not being able to commit to timeframes… I do work on a programming team as well and we face similar dilemma's! It's just I've been saying to my superiors for the last 3 years at least that you guys are working on this… and to be patient! However I hope you understand… if you admit there's a chance even that it may not be fixed within the next 4 years… I really need to come clean now and start looking for alternatives before all our customers abandon us!
Best regards,
Dave Dansey
Pentana Ltd.
Hi Dave,
We made several attempts to provide this functionality for the current version of the WPF RichEditControl, but all of them were unsuccessful. We have plans to continue researching the issue in the upcoming v15.1 release. However, I cannot provide you with any estimates in this case because of the complexity of this task. Thank you for your understanding.
>>are working on a brand new "lighter weight" version, designed to be used multiple times in a form, with auto-sizing, like normal text boxes?<<
According to our current plans, we are not going to rewrite the control from scratch to implement its "light weight" version. We will do our best to redesign the current version of RichEditControl this way.
We will update this thread once we have any results. Please stay tuned to our announcements.
The following workaround works for me (not a nice one, but it works):
private void RichEditControl_RtfTextChanged(object sender, EventArgs e)
{
PerformAutoHeight();
}
public void PerformAutoHeight()
{
Height = 16000;
Dispatcher.BeginInvoke(new Action(async () =>
{
await Task.Delay(10);
var svp = FindUIChild<SimpleViewPage>(this);
if (svp != null)
Height = svp.Height;
}));
}
public static T FindChild<T>(DependencyObject parent)
where T : DependencyObject
{
// Confirm parent and childName are valid.
if (parent == null) return null;
T foundChild = null;
int childrenCount = VisualTreeHelper.GetChildrenCount(parent);
for (int i = 0; i < childrenCount; i++)
{
var child = VisualTreeHelper.GetChild(parent, i);
// If the child is not of the request child type child
T childType = child as T;
if (childType == null)
{
// recursively drill down the tree
foundChild = FindChild<T>(child, childName);
// If the child is found, break so we do not overwrite the found child.
if (foundChild != null) break;
}
else
{
// child element found.
foundChild = (T)child;
break;
}
}
return foundChild;
}
Hello Patrick,
Thank you for sharing your workaround. We greatly appreciate it. I recommend you add this ticket to your Favorites (click the "Add to Favorites" button on this ticket's page) to be automatically notified when the auto sizing functionality is implemented out-of-the-box.
Hi Patrick ,
brilliant! Thanks!
We also need this feature working.
The workaround above is half working. You should actually check all the siblings of that first SimpleViewPage, find their location in relation to their parent and add the size. Take the Max of these siblings and you have your height.
Something like this (the richEditControl1 box is within a groupbox(this) for me):
public void PerformAutoHeight()
{
Dispatcher.BeginInvoke(new Action(async () =>
{
if (richEditControl1.VerticalScrollPosition != 0) SetVerticalScrollbarPosition(0);
await Task.Delay(10);
var sv = FindChild<SimpleViewPage>(richEditControl1);
var parent = sv.Parent as Canvas;
var maxH = sv.Height;
foreach (var child in parent.Children)
{
var tb = child as Control;
if (tb != null)
{
UIElement container = VisualTreeHelper.GetParent(tb) as UIElement;
Point relativeLocation = tb.TranslatePoint(new Point(0, 0), container);
var top = relativeLocation.Y + tb.ActualHeight;
maxH = Math.Max(top, maxH);
}
}
Height = maxH + 50;
}));
}
private void SetVerticalScrollbarPosition(int pos)
{
if (richEditControl1.VerticalScrollBar != null)
{
richEditControl1.VerticalScrollBar.Value = pos;
dynamic scrollbar = richEditControl1.ActiveView.GetType().InvokeMember("VerticalScrollController", BindingFlags.Instance | BindingFlags.NonPublic | BindingFlags.GetProperty, null, richEditControl1.ActiveView, null);
scrollbar.UpdateScrollBar();
scrollbar.ScrollToAbsolutePosition(0);
richEditControl1.ActiveView.GetType().InvokeMember("OnVerticalScroll", BindingFlags.Instance | BindingFlags.NonPublic | BindingFlags.InvokeMethod, null, richEditControl1.ActiveView, null);
this.Refresh();
}
}
Hi,
we still need this feature. is it completed?
thanks
Hi Patrick,
Our current attempts to fix this issue were unsuccessful. So, most probably, we will postpone this task for the current release.
I would like to note that we introduced the Layout API feature for RichEditControl in v15.1 (Add a corresponding API that allows analyzing Document Model layout). The main entry point of the Layout API is the RichEditControl.DocumentLayout property. This property provides access to the DocumentLayout object containing basic properties and methods for working with document layout objects.
It is possible to use this functionality to calculate the RichEditControl height and implement the auto-height feature for RichEditControl in a custom manner. You can find a sample that shows this approach in the Ability to resize the RichEditContlol based on its content within the LayoutControl ticket. I hope you will find this information and sample useful.