Lab 18

0. This paper submitted by

1. The disk drive is divided into sectors and when any information is needed in a sector the whole sector is read into memory into a buffer and then the buffer is searched to find the piece of information the program requested. The information could be changed and replaced in the buffer as long as the change did not overlap other data in the buffer or change the buffer’s size. The buffer could then be re-written to its place on the disk. This is called update in place. To make this possible, we have to arrange that each field and each record are always a fixed size. Then when we update the fields we can write the record back into the same space in the buffer. We know the size of each data type, and the range of values that each holds. Random access files are like arrays because we can compute the location of any record in the file by knowing its sequence number in the file. Like arrays, we (the compiler) can determine the address of that record in the buffer and read or write the specified number of bytes to that location. But since records are not a data type known to the compiler (built-in) we have to declare them. How many bytes will each ClientRecord (p.617) require?
   
   
2. What are some of the rules you must observe when declaring a Type?
   
   
3. Members of Types are referenced like properties of controls, using the period or field notation. The author warns that you cannot simply define a type to be any collection of fields because the computer requires certain fields to start on certain address (word boundaries) and thus will increase the size of your record by skipping over bytes to reach the next appropriate starting position for that data type. LenB is a function that can measure how much space the record type was allocated by the compiler, and thus the program can be written to find and use that value to place in or retrieve the records out of the buffer properly (but LenB must take a data item, not the record type name). The author uses a different file dialog box than the one that comes in the toolbox, so he gives directions for adding it to the toolbox. Follow those directions, then open a blank form and place the CommonDialog box on the form and observe its property table. Try to change its size. Run the form. What did you learn?
   
   
4. Add a command button to the form and place the statement
   CommonDialog1.ShowOpen
   in the ….._Click() event procedure and run the form again. While in design mode look at the attributes of CommonDialog1. (note that FileTitle is not in the property box because it is not possible to give FileTitle a value at design time).
   
   
5. State the format (it is like the For statement, it has several phrases) of the Open statement (can any phrases be omitted?)
   
   
6. In the previous chapter we use an FSO object to access the file, in Fig 15.4 we use VB’s built-in file statements that assign each file a number and use GET # and PUT # statements within the code (not very meaningful to the reader). The access statements must tell the compiler what file (buffer), what record #, and what data area is either being read or written for the transfer to be generated. The Close# statement insures that the buffer gets copied back to disk. With the record # (starting at 1) and the LEN argument, the compiler can calculate what byte address in the buffer to access. Fig 15.5 shows the code to write non-empty records to a file. This time an unknown number of records will be written. How does this affect the code (there are now more procedures)?
   
   
7. When it comes to accessing these records (reading them back), how will the read program know what byte addresses in the buffer represent records and which were not initialized (how will the read program know how many records there are in the file)?
   
   
8. Fig 15.6 answers the previous question partially. We don’t know what file the user of programs 15.5 and 15.6 selected from the CommonDialog but we might hope that it was the same file created in Fig 15.4. If so, we know that that program formatted the file (buffer) with a zero in the accountNumber field for 100 records. Program 15.5 then overwrote some of those 100 records with non-zero account numbers. Program 15.6 will therefore find some non-zero account number fields and some zero account number fields when it reads the buffer using the same ClientRecord template. What do you suppose happens if any of these assumptions are wrong?
   
   
9. Program 15.6 could easily be modified by adding the following statement after the DO in cmdNext_Click(): x=InputBox(“Input record # <=100”)
   (with a DIM x As Integer statement in front of the DO) and changing the
   Get #1, , mUdtClient statement to Get#1,x,mUdtClient
   We would then not be accessing the file sequentially we would be accessing its records randomly (in any order). What problems would this change generate?
   
   
10. The program in Fig. 15.7 makes the above change except it changes the name of the Next button and uses the Account Number text box to obtain the record number instead of an InputBox. There is no loop since the user drives the program. There is no test for EOF(1). Since program 15.5 used the account number value to select the record slot in the buffer to write into, when program 15.7 uses the record number to choose a slot to retrieve a record from, it should be the same record. Unlike the sequential reading of 15.6, we can assume that we are only interested in valid (previously initiated) accounts, so we would not expect to be reading out of slots prepared for as of yet unused account numbers. The author then presents Fig 15.8 as a complete program for creating a listing of the file’s contents, initializing and zeroing a slot (adding or deleting an account), and updating the balance field of the record stored in the slot corresponding to its account number. The GUI corresponding to his picture is the ssTab component called Microsoft Tabbed Dialog Control 6.0 which can be added to the toolbox. By examining its properties table you can see how the number of tabs is determined and how each is captioned. Each tab page is a container for other controls. The CommonDialog control is used to input a file name to open for random access, and then used again when a file name is needed to create a text file. What would happen if the same name were input both times?
    
    
11. How do these two files differ (what do you see if you open each in Notepad)?
    
    
12. There are two new statement keywords in Sub cmdTextFile_Click() on p. 634.
    What are they and what do the statements they identify accomplish?
    
    
13. Understand that you must always write a file before you can read it (file programs always have both a write component to create the file and an update component to maintain the file). However, you sometimes want to update the file by appending additional information on to it. When you write a file and close it, the system keeps a record of the number of bytes that you transferred to the buffer (the file size). The operating system also places a marker after the last byte you transferred, the EOF marker. All the examples in this chapter have been predicated on initially formatting the file as blank records, thus determining the size. If you write the file sequentially, its size increments after each successive record, and each new record terminates with an EOF marker just in case you don’t write again to the file. In this way the operating system always knows were the end of the file is, and it knows if you ask it to read or write off the end, so you must stay in the contiguous file area. You can position at the end of the file and extend its size with new records, writing either randomly or sequentially. However, the file will normally open for writing sequentially at its beginning, which means that the default is to overwrite a file with sequential writes (Put without a record number), thus automatically changing its size to that of the first record you write. Random writes, (Put with a record number) does not include an EOF marker after each record written, so it does not change the size of the file unless it is a write at the end., in which case it is treated as a sequential write. Each time you read or write sequentially the file pointer is pushed to the next position to read or write. The seek statement repositions the file pointer so that the next read or write will occur at a different position from the current position. The file pointer is not affected by random reads and writes. If you have just performed a sequential write, what does the file pointer point at?