Paragraph.Text? Should there be a dependency property as well?

I'd like to set up databinding to a Paragraph object. Paragraph has a
Text field, and I would like bind this to a particular cell in a
DataTable. I thought that one would do this using some code like the
following:

Paragraph p = new Paragraph();
Binding b = new Binding("Table.Rows[" + rowCount + "][" + columnCount
+ "]");
b.Mode = BindingMode.TwoWay;
b.Source = this.DataView;
p.SetBinding(Paragraph.TextProperty, b); // does not compile!

This doesn't compile because Paragraph does not have a static dependency
property for it's Text property in a similar way that a TextBlock does.
Was this purely an oversight and it will be incorporated in a future
release, or is this by design?

Regards,
Jason

I believe that's intentional, I have no clue why, but it is. The
solution is to derive from Paragraph and make a DependencyProperty for
it.

And to Avalon folks- this is what makes templates completely worthless.
Paragraph, Hyperlink, etc are all unuseable in templates. Do you guys
actually use this stuff before you send it out? When you made the
*text* property on paragraph and hyperlink *unuseable* from templates
what were you thinking???

Sorry for my previous rant, it's just that when I hear all this hype
about templates and styling, then can't use a simple hyperlink in one,
it makes me think microsoft is full of ****. I drank the koolaid and
saw productivity plummet trying to work around crap like this.

I had this problem before with Hyperlink, so I have put a TextBlock inside
the Hyperlink and use its Text property for data binding. I presume it will
work for Paragraph too.

Regards,
Valentin

"Jason Dolinger" wrote:

> I'd like to set up databinding to a Paragraph object. Paragraph has a
> Text field, and I would like bind this to a particular cell in a
> DataTable. I thought that one would do this using some code like the
> following:
>
> Paragraph p = new Paragraph();
> Binding b = new Binding("Table.Rows[" + rowCount + "][" + columnCount
> + "]");
> b.Mode = BindingMode.TwoWay;
> b.Source = this.DataView;
> p.SetBinding(Paragraph.TextProperty, b); // does not compile!
>
> This doesn't compile because Paragraph does not have a static dependency
> property for it's Text property in a similar way that a TextBlock does.
> Was this purely an oversight and it will be incorporated in a future
> release, or is this by design?
>
> Regards,
> Jason
>

loser wrote:

> Sorry for my previous rant, it's just that when I hear all this hype
> about templates and styling, then can't use a simple hyperlink in one,
> it makes me think microsoft is full of ****. I drank the koolaid and
> saw productivity plummet trying to work around crap like this.

I think you need to take a step back and realize this is a "work-in-progress"
code base your playing with and the only reason it's in the public's hands
at all is so that we can provide constructive feedback on things like this.
Maybe if you shared your templating scenario with the group or entered it
into LadyBug Microsoft would get a chance to understand your scenario and
see that maybe these features do need to be implemented.

Later,
Drew

loser wrote:
> I believe that's intentional, I have no clue why, but it is. The
> solution is to derive from Paragraph and make a DependencyProperty for
> it.
>
> And to Avalon folks- this is what makes templates completely worthless.
> Paragraph, Hyperlink, etc are all unuseable in templates. Do you guys
> actually use this stuff before you send it out? When you made the
> *text* property on paragraph and hyperlink *unuseable* from templates
> what were you thinking???
>

Ok, so let's say I do something like that:


public class BindableCell : Paragraph
{

public static readonly DependencyProperty TextProperty = null;


static DataGridCell() {
TextProperty = DependencyProperty.Register(
"Text", typeof(string), typeof(BindableCell ), new
PropertyMetadata(1));
}


}

How exactly does this dependency property get tied to the existing
"Text" property inherited from the Paragraph?

Thanks for the help!
Jason

Jason Dolinger wrote:
> loser wrote:
>
>> I believe that's intentional, I have no clue why, but it is. The
>> solution is to derive from Paragraph and make a DependencyProperty for
>> it.
>>
>> And to Avalon folks- this is what makes templates completely worthless.
>> Paragraph, Hyperlink, etc are all unuseable in templates. Do you guys
>> actually use this stuff before you send it out? When you made the
>> *text* property on paragraph and hyperlink *unuseable* from templates
>> what were you thinking???
>>
>
> Ok, so let's say I do something like that:
>
>
> public class BindableCell : Paragraph
> {
>
> public static readonly DependencyProperty TextProperty = null;
>
>
> static BindableCell() {
> TextProperty = DependencyProperty.Register(
> "Text", typeof(string),
> typeof(BindableCell ), new PropertyMetadata(1));
> }
>
>
> }
>
> How exactly does this dependency property get tied to the existing
> "Text" property inherited from the Paragraph?
>
> Thanks for the help!
> Jason

Ah hah! This does is:


public class BindableCell : Paragraph
{

public static readonly DependencyProperty BlahProperty = null;


static BindableCell() {
TextProperty = DependencyProperty.Register(
"Text", typeof(string),
typeof(BindableCell), new PropertyMetadata(new
PropertyChangedCallback(TextUpdated)));
}

private static void TextUpdated(DependencyObject d,
DependencyPropertyChangedEventArgs e)
{

BindableCell cell = d as BindableCell;
cell.Text = (string) e.NewValue;

}
}

Is this the best approach?

Jason

Jason Dolinger wrote:

> Ok, so let's say I do something like that:
>
> ... code snipped for brevity's sake ...
>
> How exactly does this dependency property get tied to the existing
> "Text" property inherited from the Paragraph?

Before I even answer the question, I'd just like to give a little insight
into why I think Paragraph's Text property isn't a DependencyProperty right
now. The truth is, it's not a property at all. Even though it's presented
as a CLR property, what's happening under the covers is that the Paragraph
class is using the TextPointer API to grab it's content out of (or replace
the content in) the TextRange it belongs to. It's nice of the Paragraph class
to abstract away the TextRange API like this, in fact I'm sure more people
would be kicking and screaming if it weren't designed as a CLR property because
then they'd have to do all the TextRange work themselves. That said, it *could*
still be a DP AFAICT, but maybe Microsoft has a good reason not to make it
one that I'm missing.

Now, as to how to "turn it into" a DP with your own subclass...

When registering the DP, you need to pass an instance of FrameworkPropertyMetaData.
You should probably look at configuring the metadata correctly so it supports
binding, doesn't support animation, etc., but the most import thing is to
set the Get/SetValueOverride properties to delegate instances that you then
use to access the base class' Text property from. Something like:

private static object MyGetValueOverride(DependencyObject do)
{
return ((Paragraph)do).Text;
}

private static void MySetValueOverride(DependencyObject do, object value)
{
if(value == null)
{
throw new ArgumentNullException("value");
}

string text = value as string;

if(text == null)
{
throw new ArgumentException("Expected a string.");
}

((Paragraph)do).Text = text;
}

HTH,
Drew

> I'd just like to give a little insight into why I think Paragraph's Text
> property isn't a DependencyProperty right now. The truth is, it's not a
> property at all. Even though it's presented as a CLR property, what's
> happening under the covers is that the Paragraph class is using the
> TextPointer API to grab it's content out of (or replace the content in)
> the TextRange it belongs to.

Rich text is a lot more complicated than plain text, which is almost
certainly part of the story. But we're not entirely consistent here,
TextBox.Text and TextBlock.Text are data bindable DP's, but Paragraph.Text &
Span.Text is not. (that's plain text binding -- rich text data binding is
complicated enough that we don't plan to do that in v1) We'll investigate
this and see if we can add data binding to those .Text properties, thanks
for bringing this to our attention.

-Nick Kramer [MSFT]
http://blogs.msdn.com/nickkramer

---
This posting is provided "AS IS" with no warranties, and confers no rights.
Use of included script samples are subject to the terms specified at
http://www.microsoft.com/info/cpyright.htm


"Drew Marsh" <drub0y@hotmail.no.spamming.com> wrote in message
news:f01844f1e22348c7df7737205694@msnews.microsoft.com...
> Jason Dolinger wrote:
>
>> Ok, so let's say I do something like that:
>>
>> ... code snipped for brevity's sake ...
>> How exactly does this dependency property get tied to the existing
>> "Text" property inherited from the Paragraph?
>
> Before I even answer the question, I'd just like to give a little insight
> into why I think Paragraph's Text property isn't a DependencyProperty
> right now. The truth is, it's not a property at all. Even though it's
> presented as a CLR property, what's happening under the covers is that the
> Paragraph class is using the TextPointer API to grab it's content out of
> (or replace the content in) the TextRange it belongs to. It's nice of the
> Paragraph class to abstract away the TextRange API like this, in fact I'm
> sure more people would be kicking and screaming if it weren't designed as
> a CLR property because then they'd have to do all the TextRange work
> themselves. That said, it *could* still be a DP AFAICT, but maybe
> Microsoft has a good reason not to make it one that I'm missing.
>
> Now, as to how to "turn it into" a DP with your own subclass...
>
> When registering the DP, you need to pass an instance of
> FrameworkPropertyMetaData. You should probably look at configuring the
> metadata correctly so it supports binding, doesn't support animation,
> etc., but the most import thing is to set the Get/SetValueOverride
> properties to delegate instances that you then use to access the base
> class' Text property from. Something like:
>
> private static object MyGetValueOverride(DependencyObject do)
> {
> return ((Paragraph)do).Text;
> }
>
> private static void MySetValueOverride(DependencyObject do, object value)
> {
> if(value == null)
> {
> throw new ArgumentNullException("value");
> }
>
> string text = value as string;
>
> if(text == null)
> {
> throw new ArgumentException("Expected a string.");
> }
>
> ((Paragraph)do).Text = text;
> }
>
> HTH,
> Drew
>
>

Nick Kramer wrote:

> Rich text is a lot more complicated than plain text, which is almost
> certainly part of the story. But we're not entirely consistent here,
> TextBox.Text and TextBlock.Text are data bindable DP's, but
> Paragraph.Text & Span.Text is not. (that's plain text binding -- rich
> text data binding is complicated enough that we don't plan to do that
> in v1) We'll investigate this and see if we can add data binding to
> those .Text properties, thanks for bringing this to our attention.

Looking at how TextBlock does it, my guess is that they left it out of these
document specific elements because it would add soooo much overhead to complex
documents. Every Paragraph/Span would not only store it's text in the DP
cache (for all the benefits of DPs), but also in the TextContainer they're
associated with. So if you had a 10 page document with 100 some odd Paragraphs
you'd have 100 strings of varying sizes stored in the DP engine as well as
the same amount of string data stored in the underlying TextContainer.

Also, wouldn't you need to hook the Change event of the underlying TextRange
of the Paragraph/Span? Just thinking of the scenario where someone comes
in through the TextRange API and modifies part of the Paragraph/Span. I would
think the expected thing would be for the DP value to be updated. This adds
all the overhead of hooking an event handler to every Paragraph/Span. I don't
actually see that being done anywhere in TextBlock, maybe that's an expected/acceptable
limitation though?

Anyway, that's just my best guess at why they made the sacrafice... you would
certainly know better than I.

Cheers,
Drew