Modifiying the Databound aspects of a WPF Control
I want to construct my DataBound PasswordBox control for my application as the current
DataBound PasswordBox control does not offer Databinding. Ignoring a previous post on
the forum regarding why you would want a DataBound PasswordBox, I thought it would be
best to either extend the TextBox User Control or the PasswordBox Control.
If I base on the PasswordBox then I would need to add Databinding support which I dont know
yet hoe to do. If I extend the TextBox Control then I have most of the DataBinding facility I need
and I only need to add the visuals.
I tried the TextBox approach and basically added a property to contain the text data. I now want
the data binding for the control to reference my local property and not the TextBox Text property.
How do I do this?
Is it best to extend TextBox or Password Box?
Is there a better way to do this?
Has anyone already done such a control?
Thanks in advance for the advice
Answers
For providing boundable property you have to implement any Dependency Property for control being customized and provide appropriate Binding later on using either Xaml or code behind. Try using default "propdp" snippet in Visual Studio to see what does it provide you with.
Speaking about subclassing and extensions guess you should take appropriate dedicated control for that. In your case it will be PasswordBox. You should also take into consideration possible security breaks within you subclass so be careful with that. Having a plain TextBox control used to maintain passwords will provide end-users with possibilities of hacking/getting it via Snoop or whatever layout disclosing tools

All Replies
For providing boundable property you have to implement any Dependency Property for control being customized and provide appropriate Binding later on using either Xaml or code behind. Try using default "propdp" snippet in Visual Studio to see what does it provide you with.
Speaking about subclassing and extensions guess you should take appropriate dedicated control for that. In your case it will be PasswordBox. You should also take into consideration possible security breaks within you subclass so be careful with that. Having a plain TextBox control used to maintain passwords will provide end-users with possibilities of hacking/getting it via Snoop or whatever layout disclosing tools

Steven Hawkes wrote: Ignoring a previous post on the forum regarding why you would want a DataBound PasswordBox. . .
That's an interesting thing to ignore... There's a reason the control was written in this manner.
Once you have developed your control, please let me know which applications are using it so I can avoid using them.
Thx, Will give it a try
Whilst trying the proposal above I get an error I dont quite understand. Note : Was unable to extend PasswordBox as it is a sealed class so continued with the TextBox approach. The error I get is
{"A 'Binding' cannot be set on the 'Field1' property of type 'DBBox'. A 'Binding' can only be set on a DependencyProperty of a DependencyObject."}
My hunch is that DBBox should extend DependencyObject but then I would be unable to extend the TextBox.
Do I really need to factor out the Field1 to a seperate class that extends DependencyProperty or am I missing something simple here?
TIA
Code Snippet<
TextBox x:Class="DBBox" xmlns="http://schemas.microsoft.com/winfx/2006/xaml/presentation" xmlns:x="http://schemas.microsoft.com/winfx/2006/xaml" TextChanged="TextBox_TextChanged">
</
TextBox>
public partial class DBBox : TextBox{
public DBBox(){
InitializeComponent();
}
get { return (string)GetValue(Field1Property); } set { SetValue(Field1Property, value); }public string Field1
{
}
public static readonly DependencyProperty Field1Property =
DependencyProperty.Register("Field1", typeof(string), typeof(DBBox), new UIPropertyMetadata(""));
}private void TextBox_TextChanged(object sender, TextChangedEventArgs e)
{
}
- I would guess that a large percentage of apps don't encrypt passwords the instant a user types them into a text box. I absolutely agree that a password should never go across the wire, or to disk, in clear text, but do all apps really need such tight security that passwords must be encrypted even while they're in memory?
In any case, unless I'm missing something, the design of PasswordBox isn't completely hacker proof. There's no SecureString type property on PasswordBox that will allow you to preserve the encryption of a password as you read it: instead you have to use the Password property which provides the result in clear text. Likewise, there aren't many APIs that will recieve a SecureString. So at some point, the current design of the .Net APIs forces you to keep passwords in clear text, and I don't see that keeping them in Dependency Properties is much worse. I'm happy to be corrected.
With this in mind, I created an extension to PasswordBox using Attached Properties that allow the password on PasswordBox to be data bound in those situations where a developer has ascertained that this isn't going to reduce the security of the system any further. You can get the code here: http://blog.functionalfun.net/2008/06/wpf-passwordbox-and-data-binding.html


