Ask a questionAsk a question
 

AnswerModifiying the Databound aspects of a WPF Control

  • Monday, March 31, 2008 7:12 AMSteven Hawkes Users MedalsUsers MedalsUsers MedalsUsers MedalsUsers Medals
     

    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

  • Monday, March 31, 2008 8:33 AMDenis Vuyka Users MedalsUsers MedalsUsers MedalsUsers MedalsUsers Medals
     Answer

    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 Wink

     

All Replies

  • Monday, March 31, 2008 8:33 AMDenis Vuyka Users MedalsUsers MedalsUsers MedalsUsers MedalsUsers Medals
     Answer

    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 Wink

     

  • Monday, March 31, 2008 8:39 AMDr. WPF Users MedalsUsers MedalsUsers MedalsUsers MedalsUsers Medals
     
     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.

  • Monday, March 31, 2008 7:16 PMSteven Hawkes Users MedalsUsers MedalsUsers MedalsUsers MedalsUsers Medals
     

    Thx, Will give it a try

  • Tuesday, April 01, 2008 6:55 PMSteven Hawkes Users MedalsUsers MedalsUsers MedalsUsers MedalsUsers Medals
     

    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();

    }

     

    public string Field1

    {

    get { return (string)GetValue(Field1Property); }

    set { SetValue(Field1Property, value); }

    }

     

    public static readonly DependencyProperty Field1Property =

    DependencyProperty.Register("Field1", typeof(string), typeof(DBBox), new UIPropertyMetadata(""));

     

    private void TextBox_TextChanged(object sender, TextChangedEventArgs e)

    {

    }

    }

     

  • Monday, June 23, 2008 10:06 AMSamuel Jack Users MedalsUsers MedalsUsers MedalsUsers MedalsUsers Medals
     
    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