Broken: RichTextBoxes with embedded UIElements
If you've been using the BlockUIContainer or InlineUIContainer elements in a FlowDocument, embedded within a RichTextBox, AND want the embedded UIElements to be enabled in V1 of WPF/.NET 3.0, give up now.
<RichTextBox>
<FlowDocument>
<Paragraph>
<Run>
Here is some text in a paragraph
</Run>
</Paragraph>
<BlockUIContainer IsEnabled="True">
<Button Click="BlockUIClick" IsEnabled="True">Click me please!</Button>
</BlockUIContainer>
<Paragraph>
<Run>
Here is some text in a paragraph after a control.
</Run>
</Paragraph>
<Paragraph>
<Run>
Here is some text in a paragraph
</Run>
<InlineUIContainer>
<Button Click="InlineUIClick">Click me!</Button>
</InlineUIContainer>
</Paragraph>
</FlowDocument>
</RichTextBox>
As of the released version of WPF/.NET 3.0, this functionality no longer works at all if you want the control to actually be enabled -- and appears to be intentional/as expected. Several Microsoft employees have stated as much in forum posts.
http://forums.microsoft.com/MSDN/ShowPost.aspx?PostID=389348&SiteID=1
http://forums.microsoft.com/MSDN/ShowPost.aspx?PostID=716043&SiteID=1 (look for a post by Prajakta Joshi)
I'm disappointed to say the least that this wasn't included in the final V1 release, as it's something the company I work for would absolutely have used. I really hope it returns in V2.
Here are some links to a couple of other pages where this was documented as working:
Comments
It turns out that you can trick the system to allow enabled controls in RichTextBox.
You can supply the FlowDocument to be used by a RichTextBox by passing it to the RichTextBox constructor or by setting the Document property.
If instead of passing a normal FlowDocument, you pass a derived class that overrides the special check used to disable controls in the RichTextBox, you can have a RichTextBox that contains enabled controls.
Here's the class that allows enabled controls:
class EnabledFlowDocument : FlowDocument
{
protected override bool IsEnabledCore
{
get
{
return true;
}
}
}
The WPF team probably disabled this for a really good reason, but that's the hack if anyone wants to play around.
Posted by: Alex Stockton | January 5, 2007 2:05 PM
Your workaround seems promising. The first problem I see is that any event handler bound to the control are lost upon delete/undo-delete
Posted by: Chris Evans | January 16, 2007 11:43 PM
Chris -- deleting a control in the text box and then undeleting?
Posted by: Aaron | January 25, 2007 8:57 PM