Lab 17

0. This paper submitted by
1. chapter 14 begins with the discussion of the file controls that we reviewed last week. The program in fig14.4 connects the dirBox to the new drive selected whenever the dirBox changes (remember, each control initializes itself to the default drive, and directory so they all agree initially). The program does not show connecting the FileListBox to the DirListBox, but the statement is shown on p 582 and it would be embedded in a DirListBox_Change() event procedure. The event handler takes care of the problem of the drive not being available—the system cannot read its directory structure (Err.Number = 68). The author has used different MessageBox formats throughout the text (since section 10.11), and here he illustrates a call to box that shows Retry and Cancel buttons. He is suggesting that if the a: drive is not ready and you cancel a drive change to a: as a consequence, that you should move to c: as a consequence. Change his code so that you stay on the drive setting you were previous to the change (You will need a global variable that gets initialized on Load to the default drive). Insert your .frm file here
2. In section 14.4 the author illustrates how to select which libraries the IDE will reference when it compiles your code. The Microsoft Scripting Runtime library is NOT referenced by default, so you will have to go to the Projects menu and check it.
3. When this library is installed, you can use the methods shown in Fig 14.8, but this is a different kind of VB component from those we have used so far. It is a runtime object, not an OLE control, so it has no property table and the IDE cannot allocate its memory at design time as with the others. Instead, as shown in Fig. 14.9, it is declared in a Dim statement in the General area (global, static) As New FileSystemObject. Once the IDE has complied this declaration, the program of Fig. 14.4 can be extended to show in a multi-line text box all the information that the FileSystemObject provides. How is the visible size of the textbox determined?
4. The menu editor has been used at design time to create a File menu (shown in the first picture on p. 589) and the menu, from the event procedures, include CreateFolder, DeleteFolder, and Exit items (we skipped over menus in section 10.9). However, you can read the code and list below each of the FSO methods that are used in creating and destroying folders:
   
   
5. Example program Fig 14.11 points out that where the DriveBox and the DirListBox have default settings, the FileListBox does not automatically select a file. It has a List of file names, and it has a ListIndex property. Find out what value FileListBox.ListIndex is initialized to.
6. Clicking on the FileListBox control (other than on its scroll bar) selects one of the displayed lines (strings), causing it to be highlighted. How is this string used to find the size and date of the file by that name?
7. What does the name theFile mean to the compiler?
8. How do multiple lines get entered into the textbox with a single assignment statement (see page 596)?
9. What is the difference between the contents of Path and ShortPath?
10. The final FSO is TextStream, which can be thought of as a hose or drain built into the bottom of a bucket. If you connect one end to a source of text (a File) you can start and stop it and extract the amount of text that you want at one time. The various Read and Skip statements measure the amount of text you want to extract, either by a character count or until a marker is reached (two markers are provided, what are they?).
11. You can reverse the action by writing an amount of characters to the stream and thereby filling the bucket. When you write can insert markers between groups of characters. Explain what has to be done initially to connect the hose.
12. The “words” that you write to the TextStream can be grouped as “lines.” Each line can represent a record the information pertaining to one entity, and the words can be the different data values (fields) that describe that entity. A file of entity records is usually homogeneous: each line has the same number of words, each record has the same fields, each field has the same range of valid values. The EOL marker separates to successive records, and some internal character is used to delimit each field (word). But because the number of characters needed to represent different values are not the same (unless we pad and truncate the value’s string representation to force uniformity), records as in the example, each having three fields, still comprise different numbers of characters. Once we have written a sequence of records to the file we want to “rewind” the file and read these same records out. This requires that we parse the stream, finding the embedded markers and delimiters, and convert the string representations of the field values back into their original data types. The programs to build and review a sequential file are given in Figures 14.17 and 14.19. Explain how a MaskEdit control works.
13. Explain what the With statement does (p. 601).
14. Simplify Fig 14.19 by using the Split function from p. 355. Insert your revised smdRead_Click() subroutine here.
15. Fig 14.20 illustrates reading through a sequential file, looking at each record’s fields, and deciding if this record qualifies for processing (display in the textbox). The loop is Do <read record><examine/process> While <not EOF>. The user presses one of three buttons, and the button’s array index tells the program what to look for in deciding whether a record qualifies. How is the parsing of the stream in this case different from the parsing done in 14.19?
16. In this specific example, the account number and last name do not change, but the Balance does. Typically we would want to periodically find an individual’s record and update the balance. To find the record we just have to read through the file until we find the record with the right account number. We would then want to enter a new balance and write the record back to the file. What problems does this need pose? What capability would we need for the computer to have if we are to be successful?
    For example, if we could read the entire stream into memory as one long string, would we then be able to update the field in place? If this wouldn’t always work, what other capabilities might we wish for?