Add the capability to resize control based on own content size

We are currently looking for a Rich Edit control with this auto resizing feature. Any luck getting into a current release? We really like your control based on the documentation but this is a BIG requirement. Thanks.

I am afraid we have no plans to implement this feature in the next major release. Please accept our apologies for the inconvenience.

This is a big requirement for us also - we have implemented a partial 'hacky' solution, but it would be great if the control did support showing the entire content at once, using as much height as is required.

Regards,
David Dansey
Pentana Ltd.

Hi,
Thank you for your reply. We greatly appreciate your time and cooperation.
Thanks,
Alessandro.

Dear David,
Can you share you "hacky" solution with the rest of us mortals?

Thanks!
Mateo

If anyone is still interested, this is how we fixed it. We use a Windows.Forms.RichTextBox that has a method that gives the required height for the contents. So we copy content from the RichEditControl to the RichTextBox at times and in return get the required height.
Implementation:
We have a usercontrol that has a MyRichEditControl on it which derives from RichEditControl. The usercontrol is not a requirement but was needed in our case. In the usercontrol we subscribe to the myRichEditControl1_ContentChanged event and execute this
myRichEditControl1.UpdateControlHeight();
int newHeight = Math.Min(Math.Max(myRichEditControl1.Height, this.minEditorHeight), MAX_CONTROL_SIZE);
if (this.lastEditorHeight != newHeight)
{
    this.lastEditorHeight = newHeight;
    OnHeightChanged(new EditorHeightChangedArgs(newHeight));
}
Here's the most interesting part of the code that show how we do it in MyRichEditControl.
internal class MyRichEditControl : RichEditControl {
  private readonly System.Windows.FormsRichTextBox rtbHeight;
public MyRichEditControl()
{
  InitializeComponent();
  this.rtbHeight = new RichTextBox();
  this.rtbHeight.ContentsResized += rtbHeight_ContentsResized;
}
void rtbHeight_ContentsResized(object sender, ContentsResizedEventArgs e)
{
if (!suspendEventHandling)
  {
    this.rtbHeight.Height = e.NewRectangle.Height;
  }
}
public void UpdateControlHeight()
{
  this.BeginUpdate();
  switch (this.ActiveView.Type)
  {
    case RichEditViewType.Draft:
    UpdateControlHeightBasedOnContent();
  }
  this.EndUpdate();
}
private void UpdateControlHeightBasedOnContent()
{
    Control parent = this.Parent as Control;
    if (parent != null)
        parent.SuspendLayout();
    this.suspendEventHandling = true;
    rtbHeight.Width = this.Width;
    this.suspendEventHandling = false;
    rtbHeight.Rtf = this.RtfText;
    this.ClientSize = new Size(this.ClientSize.Width, Math.Max(Math.Min(rtbHeight.ClientSize.Height + GetHorizontalRulerHeight(), 65000), this.minimumControlHeight));
    #region finetune height by making use of the scrollbar
    if (this.ClientSize.Height < 65000)
    {
        var vertScrlCtrl = this.ActiveView.GetType().GetProperty("VerticalScrollController", BindingFlags.Instance | BindingFlags.NonPublic).GetValue(this.ActiveView, null) as RichEditViewVerticalScrollController;
        if (vertScrlCtrl != null)
        {
            double factor = (double)(vertScrlCtrl.ScrollBar.Maximum - vertScrlCtrl.ScrollBar.Minimum) / (double)vertScrlCtrl.ScrollBar.LargeChange;
            int newHeight = 0;
            if (factor > 1.0)
            {
                newHeight = Math.Min((int)(factor * this.ClientSize.Height), 65000);
                if (newHeight != this.ClientSize.Height)
                    this.ClientSize = new Size(this.ClientSize.Width, newHeight);
            }
        }
    }
    #endregion
    if (this.ClientSize.Height >= 65000)
        this.Options.VerticalScrollbar.Visibility = RichEditScrollbarVisibility.Auto;
    if (parent != null)
        parent.ResumeLayout();
}
I left out quite some parts of code, but this should get you started.
Drawbacks: horrible performance / extreme lag when you have pictures included in the richeditcontrol and you start to type something. You could however run this code not on ContentChanged, but on DocumentLoaded or something similar if that fits your needs.
Side note: I wonder why it is so difficult to expose a Property that shows the required height based on the content. Doesn't the control have the height somewhere internally? It would be nice if someone could explain this to me.
Cheers,
Martijn.

Thanks for sharing that. We did find two other RTEs that provide bottomless autofit modes. They both work really well. I don't want to post their names here out of respect for DevExpress. It does surprise me that they don't support this yet though…

Thank you for the feedback. Would you mind if I contact you about those names?

Hey Clint - Could you email me the names of the control you found ? glose --- mac.com.
Tx
I really want to use DevExpress but have to have bottomless ability.

email me at clintcarter1999 @ m s n . c o m and I'll share what I've learned on those and the pros and cons …

Hi Clint,
Can I contact you too? I also need this functionality…
Thanks

Hi Client,
I need it, too!
Thanks

+1!

I need it
Thanks

Elliot, Any chance of getting this functionality soon? It's been three years since this issue was first raised.
I currently have to use Microsoft's RichEdit because of this limitation in DevExpress' control but Microsoft's Control has its own issues :-(

Hi,
To my regret, we have no plans to implement this feature in the next major release. We will consider implementing it in the future. However, I cannot give you any estimate on when it will be implemented.

Hi Sergi,
Is there a possible workaround? Maybe a custom control subclassing DevExpress' RichEdit or something like that?
Thanks

Until this functionality is implemented in RichEditControl, we cannot provide you with any solution to this problem. Please accept our apologies for not being helpful this time.

Hi,
Coming to this issue again…
Do you think it would be difficult for me to implement this functionality if I but DX ultimate and have access to DX components' source code?
Or does DexExpress do custom developments of features if customers pay for them?
Thanks
Christophe

Please accept my sincere apologies for the delay in responding. I am afraid we cannot write a universal solution for this scenario, because we do not provide a custom programming service for implementing a particular feature/component based on your requirements. By custom programming service we imply writing a complete application or component according to a particular scenario or implementing features that are not built-in. If you encounter any problem when using our components in your application or have a question about them, please feel free to contact us. We will be glad to help you.

Hi Alessandro,
I'm still following this thread in the hope this feature will eventually be implemented by DevExpress.
Apologies but I don't think you've answered Chrisophe's questions - You say you can't "write a universal solution for this scenario, because we do not provide a custom programming service…" - that statement alone is contradictory and makes no sense.
I don't believe anyone is asking for "custom" (as in 'for them only') coding. I think Christophe was asking whether it would be possible to get this issue "on the roadmap for definite inclusion" (as this has been requested by many people over more than 3 years!!) - if one or more of your customers were willing to front up some extra funds.
I'm guessing that's not the case (even if everyone on this thread wanted this feature enough they'd be willing to pay extra)? Christophe was also enquiring as to whether you believe it would be difficult for him to 'do it himself' if he had access to the source code. I can only assume it IS technically challenging from your point of view as if it was easy it would have been done ages ago, right? [I remember myself a long time ago using Snoop to 'dig into' the visuals - I think the content was made up of a series of internal panels, which I think had a maximum height. I couldn't work out a way of forcing all the content into just one panel - it just added more panels internally if I remember correct].
The brief as I understand is simple - "Allow the Rich Edit Control to work in a 'mode' similar to the Microsoft in-built rich text editor". Nothing more. Nothing less. We just don't want the vertical scroll bar, the control should re-size to fit its content like the MS one does.
We place several Rich Text controls in another scrollable container - at present our clients are having to 'live with it' - but having vertically scrollable rich text controls inside a larger vertically scrollable container doesn't provide a very good experience at all… we can only go on for so long like this before we'll be forced to find an alternative 'working' solution. So in response to your last statement - yes!! we very much DO have problems using your component in our application!
I appreciate your control is great if you want to re-write Microsoft Word! But for many of us we want to turn off most of the features and make it act more like a standard text box - just with rich formatting ability :-)
Best regards,
David Dansey,
Pentana Ltd.

After thinking about this a bit, the information we want MUST already exist in the control someplace. The control needs to know how big it's content wants to be in order to display the vertical scroll bar properly. The proportions of the scroll bar are basically the total document height adjusted for the height of the visible portion of the document. If DevExpress could just expose whatever method / data the scroll bar is using we could easily resize the control manually as the document changes.
I'm actually tempted to start poking around with reflection to see if I can find out what's going on. If I can figure it out we should be able to call in to whatever private members it's using for those calculations using reflection. With access to the source code this would be even easier.

David,
I indeed was thinking along the lines of paying for having the resizing functionality being included in the control and available for all. Or coding it myself if it isn't too difficult to do if having access to the source code.
We have a similar use case as yours: we stack RichEditControls one on top of the other in a container control, to display a history of the changes that occur over time in segments of formatted text.
So we are either stuck with using Microsoft's RichTextBox, which resizes correctly but doesn't properly display specific special characters, or using DevExpress' RichEditControl, which doesn't resize itself.
Some of our customers are understanding about such issues, but others aren't, if you know what I mean.

Thank you for posting your use cases to this ticket. This will help us better understand your. I can confirm that our developers are working in this direction. Thought the issue is difficult, I believe that sooner or later we will provide you with a solution. Thus, there is no much sense to create complex workaround methods that are based upon reflection because they might stop working in the future. The only stable workaround is illustrated in the GetPixelPhysicalBounds - Get Document height in pixels ticket. We understand that it might be useful only in simple cases.
<<<
After thinking about this a bit, the information we want MUST already exist in the control someplace. The control needs to know how big it's content wants to be in order to display the vertical scroll bar properly. The proportions of the scroll bar are basically the total document height adjusted for the height of the visible portion of the document.
>>>
Yes, the corresponding values are available but they can be used only internally. The specificity of this information is that each time a part of a document is reformatted (e.g., when you press the Bold bar time to make the current selection bold), document painting occurs earlier than formatting of the entire document. Only at that last moment the correct height can be calculated. That is why in most cases this internal information might be useless for end-user code.
We will update this ticket once we have progress with this feature. Please bear with us.

Thanks Alessandro!

You are welcome! We are always glad to help you in case of any problems.

Thanks Alessandro.
Even if you can't provide a perfect solution - anything would be appreciated. Perhaps I'll be able to refactor my ugly workaround to a slightly more appealing one.

Thank you for your reply. Please feel free to contact us at any time.

Hi all,
Sure, know what you mean Christophe - sounds like our situations are near identical :)
I stopped short of using reflection, we currently set the controls initial height to 30, hide the scroll bar, then loop through each SimpleViewPage child of the RichEdit.Surface and increment the height by the ActualHeight of the child (+a bit extra)… up to a maximum of 380 (I don't think the control could ever be sized greater than this - when I tried over a year ago mind).
Thanks for the update Alessandro, great to hear your devs are looking at it - much appreciated by everyone I'm sure!

Please contact us if you experience any further difficulties.

I'm interested in such a feature too …

That's quite a few of us crying out for this now.
We're getting complaints from customers now we're rolling our software out to more and more… Our 'Property Grid' is nicely scrollable using the mouse scroll wheel - until the user hits a rich text field, which steals the mouse scroll events and provides a horrible end user experience :( It's been raised with us that when our property grid is in 'read-only' mode, the scroll bar within the rich text fields gets disabled (although the content is still scrollable using the mouse wheel or PgUp\PgDn) - I'm going to have to make it so that the scroll bar is still visible in read-only mode for now - but would love there to be no scroll bar at all in either mode.
I'm really hoping it'll be included in the next release!
Regards,
Dave Dansey
Pentana Ltd.

me too

me too.
And since the last update to 13.1.5.0 even the so called "workaround" doesn't work anymore.

Well it's been four years now since the issue was raised. They don't care it seems.

I'm interested too …

I'm also interested…

Why do so few people UpVote these tickets if they are interested?

Simply because I didn't know about that! Have now realised you can click on the small up arrow above the number :)
I've always been a bit confused why it says "1 Solution" - considering the post marked as the solution states "At present, XtraRichedit doesn't have built-in support for this functionality" - which doesn't constitute a solution in my mind!
I believe the small red tick that when you mouse-over says "Approved", means that DX have approved this for inclusion in the future - we just have no idea as to when :(
If more "Up" voting makes a difference then please, everyone… Vote it Up!!!

Our developers have taken into account the popularity of this feature request. Thank you for your comments. We will consider implementing this capability in one of future versions. Please stay tuned.

Thanks Alessandro. Please note that we had to select a different Rich Text Editor due to the lack of this feature. However, it soon became apparent that RTF is very costly in terms of the number of bytes needed vs plain text. In our user interface the user can add N number of RTF controls into a single file.
We actually decided to create a single control that could either show rich content (RTF) or plain text and convert between the two controls based on the content. Each child control contains a right click menu that allows the user to switch between Plain Text and Rich Text. It actually turned out to be very easy to create a TextBox control that sizes the height of the control based on the content. We also added some base styles into the derived TextBox class as well to reduce the need to switch to the heavier RTF based mode.
I point this out in case you guys are interested in considering something similar for the future…

There are no issues in the case of plain text, because its height can easily be measured via the Graphics.MeasureString Method.

Up voted as well. And I agree about the "solution post"…it shouldn't be marked as such.

13.1.7 has just been released!!! but still no sign of this issue being addressed :(
On the whole I am very happy with DevExpress (compared to other vendors we use and have tried)… everything else I've ever raised has been looked at \ fixed \ suggestions made etc. This is the ONE SINGLE issue\complaint I have - and unfortunately it's the highest impact one for our users. My aim is to eventually use just one component vendor for the main suite of WPF controls (we currently pay multiple subscriptions for which there is a hell of a lot of 'overlap' between the various suites).
There is unfortunately going to come a time whereby I am forced to address this issue and it would be a shame if the only way were to go somewhere else :( …still waiting patiently!
Regards,
Dave Dansey
Pentana Ltd.

Hi Dave,
We did not implement this behavior by the time the 13.1.7 version was introduced.
I would like to assure you that our developers are working on this feature.
This issue is in our To-Do list. We don't reject it and are going to implement it in the future.
However, I cannot provide you with the exact time frame, because our development cycle depends on the number of factors and any personal estimate may be misleading.
We will update the status of this ticket once this feature is introduced. Please bear with us.

Dear Oleg,
This request is 4 years old…I suggest that you change the speech to something believable ;-)
With love,
Mateo

Hi Mateo,
We are keenly aware of how necessary this feature is. I will be really glad to provide you with any estimates regarding introducing this feature. But while working on this task we have found it more complex than we initially thought and it is very difficult at the moment to estimate the exact time frame. We need to finish working on it. I assure you that our developers are working on this functionality and will do their best to implement it as soon as possible.

DevExpress Support…
We were able to develop our own solution. As you guys roll our your solution some things to keep in mind that we ended up implementing. And I'll call this the "Bottomless Mode" feature for this discussion…
* We needed to have N number of these RTF based controls on a single Form. So we used it more like a TextBox if you will.
With that said, RTF gets large very quickly especially when you have say 25 controls. Therefore, in our design we decided that the control would be able to revert between plain text and rich text. The control detects RTF automatically via DataBinding or through the property where the text/rtf value is set. This reduced the size of our documents SIGNIFICATELY.
   NOTE: One of the main reasons we went down this road was ALSO load time of the control. The 3rd party RTF control we had to go with was taking 200-500ms to load up. When you have 25 controls we are talking about 10-15 seconds just to load the RTF content. However, we were also experiencing Large Object Heap fragmentation due to the large number of objects needing more than 85k of memory.
* We needed to harvest all of the hyperlinks inside the RTF easily. It would great if you guys add a way to iterate all hyperlinks such as "foreach(Hyperlink link in control.Hyperlinks)…" etc…
* We needed a way to remove all images easily (we have a different solution for showing images).
* There are several sizing considerations:
   * The control width may change due to the user resizing the window.
      Therefore the "Bottomless Mode" must automatically detect this and adjust the height accordingly.
   * The Height of the "Page Size" must shrink/grow to fit the content and you must provide a SizeChanged and PageSizeChanged event to the consumer of the control for several different reasons.

* For DataBinding… Anytime you change the page size of the RTF then the RTF must change to reflect those new attributes even if the content is still the same. Therefore DataBinding is a little tricky. You may not want to automatically push data to the DataSource simply because the consumer/user is trying to view the data in a different way (resizing the Form/Maximizing the window). Perhaps this is an optional setting/property.
* Zoom is a very important feature for our users. The control should support this mode for any DPI (96, 120, etc).
* Bitmap: The control should provide API for taking a screen shot of itself taking into account the DPI.
    We use our control in a custom DataGridView we developed which has RTF based cells. In that design when a cell is not in edit mode the rtf control is not showing. Therefore we get a image of the control's content and show that on the cell using a Graphics.DrawImage in the Cell's PaintEvent…etc…
* In some cases we do not allow users to paste large content objects such as images. The RTF size just gets too large too fast with images and we end up with Large Object Heap fragmentation very quickly which eventually results in Out of Memory exceptions. Another option would be to scale down the image resolution for the user to reduce the memory size (we do not do that).
* SpellCheck painting must adjust it's red squiggly misspelled word indicator lines when the page size changes to auto fit the content.
* As an added bonus…it would be GREAT to see a floating menu toolbar like you see in MS Notepad when using the control like a TextBox as we are.
Good luck. Let me know when you have your solution. I would be glad to beta test it and compare it to our current solution.
~ Carter

Hi Clint,
When you say "the control would be able to revert between plain text and rich text" - do you mean the underlying content is always RTF but for speed purposes you wish to sometimes show the plain text equivalent? We too use the RichTextControl like a TextBox (many instances within a property grid [aka Form]) - but plug-in the RichTextControl for fields with RTF content and a simple TextBox for fields containing plain text - I'm not sure how useful most people would find for a "Plain Text view of Rich Text".
Agreed with resizing parts - that's the main goal, we still want the height of the control to grow\shrink as required when resizing the window and if the text is wrapped, changing the width would have a knock on effect on the height.
I'd not given the "Page" concept much though myself - the standard TextBox has no concept of pages and for us certainly, we have no reason to require "pages" within the RichTextControl when working in this 'bottomless' mode - but perhaps others do and if it didn't 'get in the way' I'd have no concern with it (although we wouldn't want to "see" the pages - just have a single continuous flow of text).
I too would be interested in hearing anything about the direction in which this is heading or to see any early implementations as well!
The other suggestions regarding bitmaps and hyperlinks etc. are all good but a bit off topic :)
Cheers,
Dave

Hi Clint,
Thank you for a detailed description of your scenario and requirements.
As far as I can see, most of them are not directly related to the issue discussed in this thread.
Not to discuss several issues in one thread and make our discussion more efficient, I have created separate tickets on your behalf. Please refer to these tickets for further correspondence on these items:

1. How to iterate through all hyperlinks within a document
2. How to remove images from a document
3. How to handle changing of a document/page size
4. Does the RichEditControl support the zoom feature
5. How to draw a RichEditControlt as a bitmap
6. How to prevent a specific content from being pasted into RichEditControl
7. How to adjust underlying lines for incorrectly spelled words
8. How to display a toolbar when working with floating objects

Hello DevExpress,
For an important project, we would like to use RichEditControl to diplay HTML content in a WPF app. We really need this control to support "MaxHeight" feature (in order to do not take too much room on the WPF view if the HTML content is small and in order to display a vertical scrollbar if the HTML content too is big).
After 4 years this feature has been requested, do you have a solution for that ?
Thanks a lot for your help.
Sylvain

Hello Sylvain,
Our developers are currently working to support this feature in the RichEditControl component. I can't provide you with exact time frames as to when this feature will be implemented. But we will do our best to implement this functionality in the next major version of our components.
You will receive a notification after the status of this ticket is changed.

This is really problem. There is a Telerik Silverlight version of RichEditControl which can handle this without any problem.

Hello Oleg,
how is the implementation of this new feature coming along? We are looking for the exact same thing. It would be great to have a functionality that is similar to the TextBox in WPF. If you set the MaxLines-property, the Textbox will automatically grow to the size needed to display the text until it reached MaxLines. After that a Scrollbar is shown.
Is this possible to implement with the RichEditControl Version 13.2?

It's not possible in 13.2 Klaus - they're working on it though - there are lots of us still waiting patiently :)

Please don't forget to vote this issue up…

Hello,
If everything goes according to our plans this feature will be introduced with version 14.1.
But I would like to note that we decided to support "auto-size" behavior only for SimpleView.

Yay! Any hint on when we can expect 14.1? We have a big release in a few weeks, and are wondering if we should wait for 14.1?

Hello Richard,
I am afraid that at present I cannot provide you with an exact time frame when version 14.1 will be released, because our development cycle depends on a number of factors and any personal estimate may be misleading.
Usually we release every major version of our products semiannually. If all goes according to plan, the next major update will be released in May or June.
You will be automatically notified when version 14.1 is introduced.

Thanks for the updates. Makes sense to only implement it in SimpleView, that's what we'd forced it to anyway :)
Look forward to the release!

Morning,Did things not go "according to plan"?  I can't see any mention of the new functionality in the 14.1 release notes :(Dave

Hi Dave,
We need some time to test this feature but still we have plans to include it into the v14.1 release. Please stay tuned, and you will be able to try this feature in the near future.

Awesome!!!  That's fantastic news - thanks Yulia!

Good news!

Really good news. We are waiting for that.

Hi,
can you confirm that the v14.1 release include this feature?
thank you very much

Hello Tobias,

Yes, I can confirm that this feature is available in version 14.1. Please note that this functionality is applicable only for the "Simple" view.

Thanks Ted, we only need it in simple view mode.

Hello Ted,
can you explain how to enable this feature?
i have now 14.1 installed :)
thank you very much

Hi,
I need to use this new functionality on a RichEditControl (WPF) . I m using 14.1 version, but this feature is not working on my project. Can you provide us a sample project using this enhancement ?
Thanks

Hi Philippe,
In 14.1 the Autosize property does not work. See https://www.devexpress.com/Support/Center/Question/Details/T114752

Hi,
So when will this feature finally be available and working?

Christophe, as far as I can see based on your comments, you need this functionality in WinForms. There, this feature is working properly. As for WPF, we're still working on it.

Ted,
Ah ok sorry I must have misunderstood. My understanding was that the feature wasn't working properly in WinForms and wasn't implemented at all in WPF. I stand corrected.

Hi,
I just wanted to say a big thank you to support and developers that made this functionality happen! It works perfectly and helps tremendously!
Thanks again!

Hi Christophe,
Thank you for your feedback. Our customers' compliments are the best reward for all of us. Please do not hesitate to contact us in the future. We are always happy to help you.

Hello,

I must use this functionality in WPF. As I see the AutoSizeMode="Vertical" setting has no effect.
Is this functionality supported in WPF? If not, do you plan to support it in the near future?
Till than is there any workaround to achieve the desired behavior in WPF?

Thanks in advance