OUR company has recognized that forms design is

Transcription

1 User Interface Standards for Forms Smart Access Dennis Schumaker User interface standards are critical for both programmer and end-user productivity. An important part of any application is Application Maintenance Forms and Dennis Schumaker shows the strategy and the code you need to create them. OUR company has recognized that forms design is part art and part science. However, by critically looking at the applications that we d developed over the years, we recognized that we could classify our forms into two major categories: Business Process Forms: These are forms created to model the specific business process that the application was primarily intended to automate. Although we can identify some specific common processes, such as adding, editing, deleting, filtering, and printing (which are discussed later), the exact nature of what the form will do is dictated by the unique business process. Application Maintenance Forms: These forms were created to support ancillary business functions like adding and editing information in various lookup tables (or other supporting tables used within the business application). Generally, all applications need some of these types of forms. These forms tend to be similar among all applications building a form to support adding and editing information in a lookup table is essentially an identical business process in any application. In many cases, a programmer needs to know very little about the specific business process being automated to develop the appropriate Application Maintenance Forms. However, a specific understanding of the business process is needed to successfully design acceptable Business Process Forms. Having recognized this difference, it became apparent that these two different types of forms would require different skill levels and knowledge of the business process on the part of our programming staff. So, we strove to develop user interface design and coding standards that would not only streamline our programming staff s development and take advantage of the differing skill levels, but also increase their knowledge of business processes. Our chosen user interface design for navigation is based on using drop-down menus. Consequently, Business Process Forms are typically found under our Activities menu (see Figure 1), and Application Maintenance Forms are found under an Administration menu (see Figure 2). Our IT department re-programmed the CD Collection database (which is included in the Source Code file at to demonstrate the standards. The remainder of this article will discuss these standards and demonstrate how they re to be implemented using this simple database as an example. This article will deal only with the development of Application Maintenance Forms, whereas an earlier article dealt with Business Process Forms. Application Maintenance Forms Application Maintenance Forms are typically found under an Administration menu item. Under the Administration menu item, for lack of a better name, we have a menu selection called Table Maintenance (see the section Setting the order later in this article). In all of our applications, we generally have supporting tables that are used throughout the application for looking up values, names, and so forth. Some applications may have 20 to 40 such tables, while others have just a few. The CD Collection that we use as our reference application has three lookup tables like the one shown in Figure 3. We were able to identify three major design considerations that are common to all Application Maintenance Forms, specifically: Figure 1. Activities menu. Figure 2. Administration menu. Smart Access December

2 Navigation: We found that we needed an easy way to navigate from one Application Maintenance Form to another. As applications get larger and the number of Application Maintenance Forms that are required increases, it becomes more difficult for the user to navigate from one form to another. Why not permit editing all of these tables within one form? Sorting: Information contained within maintenance tables is often used in printing reports. In many instances, these values are used in grouping and sorting the primary data in the reports. All too frequently, the user doesn t want the grouping and sorting to be alphabetical, ascending, or descending, but wants some other ordering that we can t predict. A user might, for instance, want to sort a list of categories by their relative importance to the business, something that we can t determine from the data and that may change over time. We built a sort by field capability within all of our maintenance tables that can be manipulated using the Sorting feature of the Application Maintenance Form. Operations: Once the proper Application Maintenance Form has been selected, the user will want to add, edit, or delete some information. We usually lock the data controls on the form when it s first opened so that the user doesn t unintentionally add, edit, or delete records. The user must click an operation button before any changes can be made. Printing: As described in my article in the November issue of Smart Access, this button generates a report based on the information in the form. Navigation When many maintenance tables are involved, it s difficult to provide navigation to these forms through a dropdown menu system. Consequently, we developed the Figure 3. Maintain Artist form. form and subform design (shown later, in the Update operations section). As the user clicks on a particular type of information in the Table list box, the subform control on the right of the form displays the appropriate subform. Here s the code that allows this to happen: Private Sub lstform_afterupdate() Select Case Me!lstForm Case 1 Me.fsubdialog.SourceObject = _ "frmmaintainformat" Case 2 Me.fsubdialog.SourceObject = _ "frmmaintainartist" Case 3 Me.fsubdialog.SourceObject = _ "frmmaintaintype" End Select The code is relatively straightforward for smaller applications. However, when working with a larger set of Application Maintenance Forms, we ve built a working table into the application. The code can then be made relatively generic by using a separate working table to store the information required to support the generic code. This makes adding additional maintenance tables into the application relatively easy, as described in the section Extending the design at the end of this article. Sorting In many instances, information contained within maintenance tables is used for printing reports; specifically in the grouping and sorting of these reports. The information in the form is normally presented in alphabetical order to make it easy to look up values in long lists. We build a sort by field into all of our maintenance tables that can be manipulated using the Sorting feature of the Application Maintenance Form (see Figure 4). The sort by field is used to order information in other than ascending/descending by data or primary key order. Basically, the users can have any order that they desire. Once the Order radio button is selected, the user can select a record in the form and use the arrows on the form to move it up or down in the list. Setting the order Much of the code for setting the order was presented in an article by Andy Baron a couple of years ago (why invent when you can borrow?). In order to reorder the sort by field in the table, the Order radio button is selected, and the move up and move down arrows are activated as shown in Figure 5. The code begins by 18 Smart Access December 2001

3 populating the list using an SQL statement based on the sort order selected on the form (alphabetical or primary key): Private Sub frasorting_afterupdate() Dim msql As String Dim mbmark As Variant msql = "SELECT * FROM tblmusiccategories" & _ " ORDER BY " With Me If!fraSorting = 1 Then msql = msql & "tblmusiccategories.musiccategory;"!cmdmoveup.enabled = False!cmdMoveDown.Enabled = False msql = msql & "tblmusiccategories.musicsortby;"!cmdmoveup.enabled = True!cmdMoveDown.Enabled = True!fsubMaintainType.Form.RecordSource = msql End With The user orders items with the up and down arrow buttons. The code that moves items up or down looks like this: Private Sub cmdmovedown_click() With Me MoveItem "Down",.fsubMaintainType.Form, _ "MusicCategoryID", dblong, _.fsubmaintaintype!musiccategoryid End With Private Sub cmdmoveup_click() Figure 4. Maintain Format form. Figure 5. Order items. Smart Access December

4 With Me MoveItem "Up",.fsubMaintainType.Form, _ "MusicCategoryID", dblong, _.fsubmaintaintype!musiccategoryid End With As you can see, each of the routines calls the MoveItem subroutine, which does the heavy lifting in this design. This MoveItem method accepts as parameters the direction to move, a reference to the form being manipulated, and a parameter array of all of the other parameters passed to it. The parameter array contains information that uniquely identifies the current record in the form: a field name, the data type of the field, and the value of the field. This information is repeated for however many fields are required to identify the record: Public Sub MoveItem(strUpDown As String, frm As Form, _ ParamArray avarpkfieldnamestypesvalues() As Variant) On Error GoTo Handle_Err Dim rs As DAO.Recordset Dim fmoved As Boolean Dim strcriteria As String Dim inti As Integer If Not frm.newrecord Then Set rs = frm.recordsetclone rs.bookmark = frm.bookmark If strupdown = "Up" Then rs.moveprevious If Not rs.bof Then rs.edit rs.fields(2).value = rs.fields(2).value + 1 rs.update rs.movenext rs.edit rs.fields(2).value = rs.fields(2).value - 1 rs.update fmoved = True rs.movenext If strupdown = "Down" Then rs.movenext If Not rs.eof Then rs.edit rs.fields(2).value = rs.fields(2).value - 1 rs.update rs.moveprevious rs.edit rs.fields(2).value = rs.fields(2).value + 1 rs.update fmoved = True rs.moveprevious While the code is lengthy, what it does is relatively simple. The code finds the current record on the form by getting a clone of the form s recordset and using the form s bookmark to position itself in the cloned recordset. The code then swaps the position of the current record with the record before or after it (depending on whether you re moving up or down). Swapping in this case means changing the value of the field used to order the records by adding or subtracting 1 from the current value. Much of the code is there to handle the first and last records in the recordset or when a new record is being added. Once the sorting value has been changed, the next step is to redisplay the subform with the records in the right order. However, the user must be repositioned on the record that he or she started with. That s the purpose of the next piece of code. The code first steps through the parameter array passed to the routine building a criteria string for the FindFirst method, using the information in the array. Once the criteria string is built, the form is required to redisplay the data, and the FindFirst method is used to reposition the user in the cloned recordset. If there s a match, the bookmark from the clone is passed to the form to put the user back at his or her original starting position: If fmoved Then For inti = LBound(avarPKFieldNamesTypesValues) _ To UBound(avarPKFieldNamesTypesValues) _ Step 3 If Len(strCriteria) > 0 Then strcriteria = strcriteria & " AND " strcriteria = strcriteria & BuildCriteria( _ avarpkfieldnamestypesvalues(inti), _ avarpkfieldnamestypesvalues(inti + 1), "=" & _ CStr(avarPKFieldNamesTypesValues(intI + 2))) Next inti frm.requery Set rs = frm.recordsetclone rs.findfirst strcriteria If Not rs.nomatch Then frm.bookmark = rs.bookmark Set rs = Nothing Exit_Here: Exit Sub Handle_Err: Select Case Err.Number Case MsgBox "Error: " & Err.Number & vbcrlf & _ Err.Description, Title:="GetNextLineNumber" End Select Resume Exit_Here Resume Update operations Aside from changing the order of the information through the ordering process, information in the subform can t be changed until the user selects an operation button, as shown in Figure 6. A user adds new information by clicking on the Add button. This works as would normally be expected, except that in order to support the Sorting feature some code needs to be added to the form to populate the sort by field in the table. Additions are added to the bottom of the order; that is, they re given the highest sort by number. If the user wants to change the record s position, he or she can manually move the record up by using the sorting controls. Here s the code to unlock a record: Private Sub cmdadd_click() FormState ("UnLocked") ControlState ("Edit") DoCmd.GoToRecord,, acnewrec Once the record is added, the following code is used in the BeforeUpdate event to assign a value to the sort by field: Private Sub Form_BeforeUpdate(Cancel As Integer) If Me.NewRecord Then Me!txtMusicSortBy = DMax("[MusicSortBy]", _ "tblmusiccategories") Smart Access December 2001

5 [Parent].Caption = "Music Category Entry/Editing" [Parent]!fraSorting.Enabled = True Delete In a similar manner, when an item is highlighted and the Delete button is pressed, the item is deleted. However, additional code must now be run to renumber the order of the items. If the item s sort by field was 12, then once the record is deleted, record 13 becomes 12, record 14 becomes 13, and so on. Here s the code that initiates the process: Private Sub cmddelete_click() If Me!fraSorting = 1 Then MsgBox "Change Sorting to Order " & _ " for Delete Operation! ", _ vbcritical, "Attention" Exit Sub LockMe (False) Call DeleteRecord(Me!fsubMaintainType.Form, _ "fsubmaintaintype", _ Me!fsubMaintainType!txtMusicSortBy, "MusicSortBy", _ "tblmusiccategories") The DeleteRecord routine is the most complicated of the routines. First, we get the user to confirm that he or she wants to delete the record: Sub DeleteRecord(lfm As Form, lsfm As String, _ lsortcon As Control, lsortby As String, _ ltblname As String) On Error GoTo Err_Delete_Click Dim intans As Integer intans = MsgBox("Delete This Record?", _ vbcritical + vbyesno, "Delete Confirmation") If the answer is Yes, we delete the record using the Access menu commands. The code then checks to see whether the user is deleting the last record. If so, we don t need to do anything else: DoCmd.SetWarnings False If lsortcon = DMax(lSortBy, ltblname) Then DoCmd.DoMenuItem acformbar, aceditmenu, 8,, _ acmenuver70 DoCmd.DoMenuItem acformbar, aceditmenu, 6,, _ acmenuver70 DoCmd.SetWarnings True Exit Sub If we re not deleting the last record, then the code gets a clone of the form s recordset and loops through, renumbering the sort by field on all of the records: Dim intcolumncounter As Integer Dim rst As DAO.Recordset Set rst = lfm.recordsetclone rst.movefirst intcolumncounter = 1 While (Not rst.eof) rst.edit rst.fields(2).value = intcolumncounter rst.update intcolumncounter = intcolumncounter + 1 rst.movenext Wend rst.close Set rst = Nothing Exit_Delete_Click: Exit Sub Err_Delete_Click: MsgBox Err.Description Resume Exit_Delete_Click Edit and Save The Edit button is used to change the values of the item. We re normally storing a unique id (an autonumber or other unique id) as a primary key in our tables. Therefore, editing the values doesn t invoke cascading deletes or updates. The code behind the Edit button is shown here: Figure 6. Form Maintain Type. Smart Access December

6 Private Sub cmdedit_click() FormState ("UnLocked") ControlState ("Edit") Saving records is just as straightforward: Private Sub cmdsave_click() DoCmd.DoMenuItem acformbar, acrecordsmenu, _ acsaverecord,, acmenuver70 ControlState ("Normal") FormState ("Locked") Cancel Finally, here s the code to let the user cancel any changes: Private Sub cmdcancel_click() UndoForm ("fsubmaintaintype") LockMe (False) ControlState ("Normal") FormState ("Locked") DoCmd.GoToRecord,, acfirst The heavy lifting in the cancel operation is in the UndoForm subroutine: Sub UndoForm(lsfm As String) On Error Resume Next DoCmd.GoToControl lsfm DoCmd.SetWarnings False DoCmd.DoMenuItem acformbar, aceditmenu, _ acundo,, acmenuver70 DoCmd.SetWarnings True 'SendKeys "{ESC}{ESC}", True Utility routines Throughout our code, we ve made use of some utility routines. The LockMe routine is used to lock or unlock the controls on the subform, depending on the parameter passed to it: Sub LockMe(YesOrNo As Boolean) With Me If YesOrNo Then!fsubMaintainArtist.Locked = True!fsubMaintainArtist.Locked = False!fsubMaintainArtist.SetFocus End With Printing The same concession that was originally made to accommodate our client s Excel users has also become a standard in our user interface design. At almost any time, except in the middle of doing an operation, the user can press a Print button and be presented with a Report Preview of the information contained on the form. In some cases, we ve found that the user prefers to look up information in a report by being able to page through the report on screen rather than scroll down to the record on the form. Providing this printing option is a feature that all users have begun to appreciate, as it lets the user avoid doing a File Print that prints all of the information in the form. The Print button is also integrated with the sorting settings; that is, the sorting settings determine the sorting and grouping in the report. This is implemented using the following code: Private Sub Report_Open(Cancel As Integer) Dim msql As String Dim mbmark As Variant msql = "SELECT * FROM tblmusiccategories" & _ " ORDER BY " If Form_frmMaintainType!fraSorting = 1 Then msql = msql & "RecordingArtistName;" Form_frmMaintainType!cmdMoveUp.Enabled = False Form_frmMaintainType!cmdMoveDown.Enabled = False msql = msql & "SortBy;" Form_frmMaintainInfoType!cmdMoveUp.Enabled = True Form_frmMaintainInfoType!cmdMoveDown.Enabled = True Me.RecordSource = msql DoCmd.Maximize In short, our user interface standards for Application Maintenance Forms are focused on a relatively straightforward design that takes each of the design components and integrates them with each other. This design provides basic functionality for all of our Application Maintenance Forms without requiring our systems analysts to specifically describe each requirement to our programmers. The programmer can move forward with very little additional guidance by using these design standards. All that s required is a list of the various tables that need to be modified and edited through the user interface. Extending the design Using our user interface design standards, we ve found it very easy to extend our design into much more complicated situations. A working table can be created in the database that facilitates the creation and easy modification and maintenance of these forms. Then generic code can be written that uses the information in the table to manage the Application Maintenance Form. A more complex Application Maintenance Form is shown in Figure 7. Application maintenance tables that are related to each other can be grouped by adding a combo box to the design. As the item in the combo box control is changed, the options displayed in the list box below that control also change. The items to be displayed in the list box are read from the working table using the following code: Private Sub cbocategory_afterupdate() Dim strsql As String strsql = "select twrktablemaintenance.id, " & _ "twrktablemaintenance.formname, " strsql = strsql & "twrktablemaintenance.formlabel, " & _ " twrktablemaintenance.category " strsql = strsql & "From twrktablemaintenance " strsql = strsql & "Where " & _ " twrktablemaintenance.category = '" & _ Me!cboCategory & "'" Me.lstDialog.RowSource = strsql 22 Smart Access December 2001

7 Furthermore, the record source for the combo box can be populated from the working table using the following SQL statement: SELECT DISTINCT [twrktablemaintenance].[category] FROM twrktablemaintenance; Once an item in the list box is clicked, the subform can also be replaced by a lookup to the working table using the following code: Private Sub lstdialog_afterupdate() Me.fsubDialog.SourceObject = Me.lstDialog.Column(1) This makes adding new items to the form as easy as adding additional rows to the working table. The table contains the fields shown in Figure 8. This extension shows how the same basic user interface concepts can be used to handle a much more complete application and yet provide the user with a similar user interface for frequent use and easy navigation. Our system designers can communicate design decisions efficiently to our programmers, our programmers have a library of reusable code, and our Figure 7. Complex Applications Maintenance Form. Figure 8. Working table for Application Maintenance Forms in datasheet mode. Smart Access December

8 users have consistent user interfaces. It s hard to argue with any of those benefits. APMFORM.ZIP at Dennis Schumaker has more than 27 years of business and consulting experience, both public and private sector. Dennis holds a bachelor s degree in mechanical engineering and a master s degree in nuclear engineering from Ohio State University, and an MBA from the University of Michigan. He s also a Microsoft Certified Professional plus Internet, a Microsoft Certified Systems Engineer (MCSE), and a Microsoft Certified Trainer (MCT). Dennis is an officer with Schumaker & Company, a management consulting and professional services firm headquartered in Ann Arbor, MI. Downloads December 2001 Source Code SNAP.ZIP Garry Robinson s download shows how to create report snapshots from Access with the click of a button. (Access 97, Access 2000) LIST2002.ZIP Andy Baron has provided a sample database that shows how to use the ListBox filling features of Access 2002 (and how to use Microsoft Form controls with Access). (Access 2002) SEQSQL.ZIP This sample database from Peter Vogel demonstrates the SQL techniques to find a list of values within a consecutive range or the largest range available. (Access 97) APMFORM.ZIP Dennis Schumaker s sample database provides the code behind the user interface standards that his company has established for managing lookup tables. (Access 2000) SA0112.ZIP and SA0112.CHM The latest update to the cumulative Smart Access index includes full descriptions of every article since the January 1999 issue of Smart Access, as well as an index to each month s Source Code files. (The index is available in SA1201.ZIP The Complete December 2001 Source Code. ) Smart Access Subscription Information: or Subscription rates: United States: One year (12 issues): $139; Two years (24 issues): $250 Canada:* One year: $154; two years: $265 Standard Other:* One year: $159; two years: $270 Single issue rate: $15 ($17.50 in Canada; $20 outside North America)* * Funds must be in U.S. currency. Editor Peter Vogel; Contributing Editors Andy Baron, Mary Chipman, Mike Gunderloy, Garry Robinson, Russell Sinclair; President Connie Austin; Executive Editor of IT Farion Grove; Editorial Assistant Micki Bailey Direct all editorial, advertising, or subscriptionrelated questions to Pinnacle Publishing, Inc.: or Fax: Pinnacle Publishing, Inc. PO Box Roswell, GA smartacc@pinpub.com Pinnacle Web Site: Access technical support: Call Microsoft at Smart Access (ISSN ) is published monthly (12 times per year) by Pinnacle Publishing, Inc., 1000 Holcomb Woods Pkwy, Bldg 200, Suite 280, Roswell, GA POSTMASTER: Send address changes to Smart Access, PO Box , Roswell, GA Copyright 2001 by Pinnacle Publishing, Inc. All rights reserved. No part of this periodical may be used or reproduced in any fashion whatsoever (except in the case of brief quotations embodied in critical articles and reviews) without the prior written consent of Pinnacle Publishing, Inc. Printed in the United States of America. Brand and product names are trademarks or registered trademarks of their respective holders. Microsoft is a registered trademark of Microsoft Corporation. Microsoft Access is a registered trademark of Microsoft Corporation. Smart Access is an independent publication not affiliated with Microsoft Corporation. Microsoft Corporation is not responsible in any way for the editorial policy or other contents of the publication. This publication is intended as a general guide. It covers a highly technical and complex subject and should not be used for making decisions concerning specific products or applications. This publication is sold as is, without warranty of any kind, either express or implied, respecting the contents of this publication, including but not limited to implied warranties for the publication, quality, performance, merchantability, or fitness for any particular purpose. Pinnacle Publishing, Inc., shall not be liable to the purchaser or any other person or entity with respect to any liability, loss, or damage caused or alleged to be caused directly or indirectly by this publication. Articles published in Smart Access do not necessarily reflect the viewpoint of Pinnacle Publishing, Inc. Inclusion of advertising inserts does not constitute an endorsement by Pinnacle Publishing, Inc., or Smart Access. The Source Code portion of the Smart Access Web site is available to paid subscribers only. Log in for access to all current and archive content and source code. For access to this issue only, go to click on Source Code, select the file(s) you want from this issue, and enter the User name and Password at right when prompted. User name Password yacht zydeco 24 Smart Access December 2001