Finally, the dossier problem is finished. It was a lot of work (most of it done in the wee hours in the morning) but I have finally come out on top. The thing that is bothering me is that I came too late to the realization that objects are fantastic. They allow for a level of abstraction that is so unique; they are like units but are so much more than just plain units.

I realize that object-oriented programming is not necessary for the IBO, but our teacher "made" us use objects. At first, I thought, I could just get away with using it for some small things, but I found out that I could do so much more with them. I feel that all my code could be converted to use objects and I will probably do it. I could not use objects entirely in my project because it was just a passing fancy, but during the last stages of implementing the calendar into my program, I realized the full potential of objects.

Now on to the real conclusion....

I have kept my word about what I was going to do. My PIM is done although I still feel there can be a lot more done. The phone book is what is truly advanced, as I have been working on that for the very longest. I still feel that the calendar can be improved upon, but sadly, I am lacking time to properly finish it according to my wishes. I will now begin to describe my telephone book (I call it TheUltimateTelephoneBook) and my Memo Maker (it is still an alpha version--at least according to me).

When we first started doing records in our class, this was the item to be written. From the moment I laid eyes upon it (the structure of the program) I knew that with a little effort this little "telephone book" would not be so little. I joked about how I can just write a very advanced telephone book, because back then, the possibilities of this program were rolling in my head.

The next unit we studied was "Pointers"; "Magnificent," I thought. With records and arrays, I was limited to the amount of memory I could use. (With the old program I had a pathetic 10 records per telephone book maximum--even with a full stack of 64K allowed by Pascal) Now I was free to do as I would, and indeed, I did. Because of the very tiny amount of memory that pointers use, it is very feasible to have linked lists of quite a few records (with me, that is about 100-250 records; I could have more than that, but it really is a waste beyond 100 records). For the sake of the program I used 200 records linked together in a list. These 200 records take about 40K memory (in the heap) and can be achieved without using the full stack (16K stack memory is sufficient). My program uses the full stack because of my directory file lister. It uses arrays (big arrays at that) to display the files in a particular directory.

Now it is time for my dossier, and I have elected to continue with the tradition of wonder and continue my work on the phone book. Now my telephone book is very advanced (at least so I feel). It is very user-friendly, and it quite verbose. I have added new features to the program such as a scrolling file selector and wonderful field editors. Another thing, that has been added is a CanClose boolean function; it was a simple yet ingenious feature found in many programs. This boolean function lets the user know, whether s/he has made any changes to the program. If this is so then the program will prompt the user to save his/her changes.

The program tries to help the lazy user; There are quick shortcuts available in Phone Editor. For instance, to save a file, the user just needs to hit <ENTER> to save the file as the file s/he opened. It may seem a waste of time, but the user really appreciates it because s/he doesn't need to type in the entire file name again.

Troubles I had programming....

The use of linked lists at first was very foreign to me, because I easily misplaced my pointers. When that happened, then entire list was as good as gone (if it wasn't already). During the version updates of Phone Editor (refer to 'What's NEW in Version 1.0'), I really learned a lot about pointers. They are economical (in terms of memory management) and they are FUNtastic to work with. To me, it is like an abstract idea, because it seems to float around in your computer memory. To refer to it, it seems that I have to think of the pointer being in space and do the programming from there. When I was writing the DeleteNode procedure, I had a really convoluted way of getting rid of the first node. Later only did I realize that there was a much faster way of doing this.

This program was designed to be user friendly, and so I went looking for code to make my program look appealing to the user. I found many, many resources in SWAG (SourceWare Archival Group). I found a lot of code in this library of Pascal code. SWAG Pascal code snippets are for advanced users, but by using their code AND modifying it, I was able to learn a whole lot more; Absolute addressing, use of (some) registers and, basically, using more of the available functions. (The only thing I did not learn was inline code and assembler).What really annoys me is the finding out about the SYSTEM.Exit function. Why was it not taught earlier? It is so much better than using SYSTEM.Halt because it pops out of the current procedure rather than terminate the entire program. This is so useful to the user because s/he doesn't have to start up the program again because the programmer would not accept his/her input.

Finally....

This is the last complimentary thing I will say :This program is great. I wrote it so that it can be used by others (non-programmers and anyone else). It is for this reason that I have made it so verbose. To travel through the list, the user only has to use the arrow keys. The records are always printed on the screen, so there is no need to have a separate choice to view.

I have thought of incorporating many other features that I talked about in Criterion A. I have a calendar unit and a window unit, but I don't have a clock unit or other "fancy" things. I elected not to use the clock because it would distract me from my work, but the other units were implemented in full. Currently, I have the full (or as full as it can get) version of TheUltimateTelephoneBook. The part of my dossier that is lacking "punch" is the Calendar/Memo Maker, because it is not as advanced as my telephone book. I still feel, I can vastly improve on Memo Maker by adding new features. For instance, I would like to have a Print Memo function, an Edit Memo function, and generally have the memo allow more than 20 lines. The reason I had the memo allow only 20 lines was because I did not want to scroll text. I could have done it easily, but it would take time to fiddle around and make it the way I would want. It is because of the lack of time that I did not fully complete my Memo Maker.

For the purpose of user documentation I will capture a few output screens and document them.

Overall, I learned a lot from this effort of mine (refer to 'Testing and Robustness') and am quite satisfied with my efforts. I feel that I have answered the problem quite well.