This is the third declaration that is essential to my approach. ^dtViewRoleFeatures is bound to gridFeatures.
Again, this is a design choice rather than a restriction. The features on a role cannot be changed in this module so there is no combo. This is part of my access control mechanism for systems I work on - note there is no containing dataset this time. ^dtRoleFeatures is the internal table of features allowed for each role.
In this example, it is only supplying hardcodes, but as above it could be fetching from storage. It is called used in the refresh process every time the user changes on gridUser to determine what will be seen in gridUserRoles.
^UserRoleList is populated by the DB_UserRoleMgr module. This is another declaration that is essential to my approach. ^dtViewUserRoles is bound to gridUserRoles. ^bsRoles is here because the roles will be presented in a combo column. ^dsRoles is the container for ^dsRoles. Your second and subsequent grids do not have to follow this approach. ^dtRoles is an internal table of roles that may be assigned to a user. In this example, it supplies three hardcoded rows of data, but the module could just as easily be reading a relational database or XML. This determines what will be seen in gridUser. ^UserList is populated by the DB_UserManager module. 
^bsPeople is the binding source that will feed into the Combo column on the grid and manage the list of persons. ^dsPeople is the container for ^dtPeople. They are completely optional in the context of a multi grid solution. People variables that follow are present is that I insist that my users are selected from a list of persons already on the system. ^dtPeople is an internal table of person numbers and their names managed in the example by the DB_PersonManager module. So each of the three grids will be bound to a datatable dtView. All are compiled into the same solution and assembly references have to be added for them as seen here: The example uses five minor assemblies to supply data - this is explained further throughout the text. I will be using these to show the impact of changing the users. Three of the five labels are significant - they are lblPersonID, lblPersonNameand lblUsername. The gridFeatures DataGridView also has only one column, a text field called dgFeatureName. The gridUserRoles DataGridView has only one column, a DataGridViewComboBoxColumn called dgRoles. The gridUser DataGridView has four columns, two text fields, dgUsernameand dgPassword, and the subsequent pair are both of type DataGridViewComboBoxColumn, dgNumberand dgPerson. The controls on the form are the three DataGridViews called gridUser, gridUserRolesand gridFeaturespulled onto the form from the Toolbox using the IDE, five labels and the Exit Button. WINDOWS GRID PANELS WINDOWS
The UI is designed using a new Windows Form Application project in Visual Studio. In this example stubs will use hard coded sample data to simulate reading the data from these tables so that you are not required to have a particular database in place to follow the example. The system has tables with all roles, all users, all features, features-for-roles and roles-for-users. The idea is that a username has a person associated with it on the primary grid, then on the second grid this user can be given any number of roles, while the third grid shows the system features associated with each role. The example is drawn from the user management area of a ticketing system I am working on. This is my effort aimed at the C++/CLI audience. Backgroundĭb_developer here on CodeProject had one of the few examples online but I found it difficult to follow. The purpose of this article is to provide a working example in C++/CLI of a form with multiple DataGridViews where the contents of the second and subsequent grids are influenced by a value selected in the previous grid.
0 kommentar(er)
