>>I would have thought that you could do it directly in XAML, but it looks like you can't. It takes some codebehind work to make it happen.
>
>I prefer it that way - the alternative would leave the control author unable to prevent an enduser messing with the internals. Actually, isn't this the way it's handled in almost all architectures?

In that case I would have expected it to be consistent. Private in the XAML and Public in the code behind seems odd.

>>It's going to take me a bit to fully get the concept of dependency properties. This helped: ...
>>But it's still going to take me a bit to understand the ramifications and the usefulness of a property that ignores you some of the time.
>
>Me too. Of course I *expect* this behaviour from, say, a 'Background' property without thinking too much about why it works. This thread did inspire me to actually try creating my own dependency property. It worked - but in your scenario I couldn't discern any real benefit over using a simple CLR property. Actually I take that back - it *should* allow me to databind the textbox.Margin to the dependency property but I haven't got that to work!
>
>Regards,
>Viv

I wrote one too. I need it for binding a database item to a custom control. That one worked ok. I'm also begging to get a feel for the importance of that precedence list. If you set a value locally in a user control, it becomes somewhat fixed. Themes and styles become an important design concepts.

And I finally found a good resource for understanding binding:

http://www.beacosta.com/blog/?m=200509

If you start with her earliest blog entries she gives good examples. Google for it was driving me nuts.