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. 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 Comments
Leave a Reply. |