In this case its a shame not to be able to use data binding.įortunately, WPF has the concept of Attached Properties that allow controls to be extended very easily.
#Passwordbox data usage password#
Sometimes your main interest in using a PasswordBox is to have the password text masked as it's typed, and encryption isn't really an issue. So internally the PasswordBox stores the password in a good old field, and in fact holds it using a SecureString - a string that is automatically encrypted in memory and obliterated when no longer needed if you Reflector PasswordBox you'll see that the Password property setter stuffs any value you set into a SecureString, and the getter reads it out for you PasswordBox appends characters one by one to the SecureString as you type them, so the password is never stored as clear text until you retrieve it through the Password property.Īs an aside, one thing I don't understand about the design is why PasswordBox doesn't provide a property to access the password as a SecureString, and so preserve the encryption? The act of retrieving the password through the Password property (as you'll have to do at some point in order to use the password) will turn it into clear text, and then you'll surely loose most of the benefit of ever having it encrypted? Perhaps someone from Microsoft can explain?Īnyhow, let's get to the point. With something as sensitive as a password it's reasonable that a control (like PasswordBox) would want to keep the data closer to its chest. The values of Dependency Properties are managed centrally by the Dependency Property sub-system so that it can handle all the data-binding and cool animation stuff (animating a password - now that would be interesting!) the consequence of this is that the data effectively becomes public property. However, it's a plain CLR property rather than a Dependency Property, so it doesn't support being the target of a Data binding.īen Westbrook of Microsoft explains in a forum post that it was not exposed as a Dependency Property for security reasons. Now PasswordBox has, as you'd expect, a Password property that allows you to get and set the password. PasswordBox is what you need whenever you want to mask the characters as a user types them: for some reason, WPF's standard TextBox doesn't support that scenario. One control which nearly had me beat was PasswordBox.
Just occasionally I find myself having to fall back on property setters and getters, poking data into controls then sucking it back again, the way Windows Forms made me earn my living. This addiction is largely driven by WPF's fantastic support for Data Binding which lets anything in the UI be data-bound to anything else.
#Passwordbox data usage code#
Like Charles Petzold, I am something of a Xamlholic: I'll try for hours to find a way of expressing my UI in pure XAML, rather than pollute its purity with C# code, even if the code could go in a code-behind file.
0 kommentar(er)
