You can set the access level of the input field sub-controls, as described previously, to Edit
, or Hide
; however, some sub-controls will override your settings as user selections warrant. That is, suppose you set the username and password access to Edit
with SQL Server authentication. But if a user switches to Windows authentication, the username and password fields are no longer applicable, so the control will disable them, effectively changing them from Edit
. But the control remembers your initial settings, so that if the user switches back to SQL Server authentication, the override goes away and the ConnectionStringManager reasserts your original setting, as illustrated in Figure 7
. In that figure, the username and password fields start with access level Edit
, with SQL Server authentication. When the user switches to Windows authentication, the control disables the username and password fields (access level Display
) as shown in frame 2. Jumping to frame 5, the user switches back to SQL Server authentication so the username and password re-enable, returning to the original access level of Edit
|Figure 7. Nested Access: Your design-time settings may change because of user actions.|
Frames 3 and 4 in Figure 7
show another interesting facet. In frame 3, the user has simply clicked on the dropdown in the database field. That click initiates a dialog with the server to obtain the list of databases to populate the dropdown. When that process completes, the control automatically selects the first server in the dropdown, which completes the set of components needed to be able to make a complete connection to the database. At that point the test button changes from disabled to unknown (orange). The user then clicks the test button and the control validates the database connection, turning the test button to green.
Note that the username field has a value of "user1." But there is no such user in the database and yet the connection was successful. How is that possible? You have probably already guessed it: Windows authentication ignores the username and password. The ConnectionStringManager is aware of this condition, so when the user switches the authentication mode back to SQL Server, the test button changes to orange, indicating that with the current credentials—which now include "user1" and its associated password—the connection has not yet been checked. If the user activates the test button at this point, it will turn red, because the nonexistent "user1" could not log in.
|Figure 8. One-Way Actions: User actions may change the design-time settings in one direction only—from less restrictive to more restrictive.|
starts with the same fields set to Display
rather than Edit
. To see this, be sure you select Disable
in the Rendering choices rather than Hide
on the main form, as shown. Now, when you open the credential form, the username and password fields start out disabled, because of the access level. It so happens that Windows authentication also wants those fields disabled, so everything is in harmony.
But what happens when you switch to SQL Server authentication? Nothing—the username and password fields remain disabled. But what happened, you protest, to the user actions overriding the design-time settings? The control's design-settings override works in only one direction; in other words, a user's actions may cause the control's fields to become more restrictive, but never less, restrictive. Otherwise, the change would violate the security of the model you designed. If you, at design time, chose to not allow users to change the application-wide username, then user actions on the credential form should not be able to countermand that decision.