Paul Vincent Craven
All Rights Reserved
The Windows NT™ program was developed using current Object-oriented programming. While employed at Investors Management Group, during my undergraduate study, I was fortunate enough to have gained experience with the Microsoft Foundation Classes (MFC). These are class libraries created by Microsoft to aid in the development of Windows programs. It was my hope to continue to use this class library, but after moving to the University of Missouri-Rolla, I did not have access to any Windows compiler.
However, the solution to this problem soon presented itself. The UMR bookstore was holding a drawing for a copy of Borland C++ 4.02. So, as permitted by the rules of the contest, I faithfully dropped my name into the drawing box every day for three weeks prior to the contest. Soon thereafter I got a call saying I had won a copy of Borland C++. So our Graphical User Interface is based on the class library that Borland makes, Object Windows Library (OWL).
I have found OWL to be more Object-oriented than MFC Yet MFC more is focused more on keeping up with all of Windows functionality. MFC's library does have a bit more in it than any other library, having over 400 control points for a significant number of its functions . With that many control points I am concerned about its future maintainability. Despite having a better theoretical base for a class library, many developers decide not to use OWL because Borland's financial stability is in question. However, to better the solar car team's financial stability I felt it was better to use the free compiler than to buy a new one.
I originally adopted the naming convention that Borland uses for its classes. Only after I started this did I realize that the "T" that was prepended to each class stood for the Borland trademark "Turbo". Ideally I would like to have all of the classes prepended with a "C" for Class, as that would be more appropriate. I did not think it worth the risk of breaking code to go back and change them all. So the naming standard for classes is not consistent in the project. A table with all the classes and functions written is available in Appendix A of this document.
Each data window class has a base of TDataWindow, derived from Borland's TWindow class. By providing a common data window base class, the window handler can treat each data window the same. For example, a graph window can be managed with the same code that handles the GPS map window. This prevents having separate code for each type of data window that is displayed. The base data window class has an update member which is called every few seconds when the processor is idling. The data windows will then use this call to check and see if the data has changed, and if it needs to dynamically update its window.
The graph window was the first type of data window that was written. It is passed a pointer to a data handling object that gives it information to graph. In this manner, the graph window can display any data or relationship without changes to the code. The graph object can create a TScaleDialog object which produces a pop-up dialog allowing the user to change graph options.
Table windows give a dynamic reading of the exact sensor readings that the solar car is sending to the chase vehicle. These are useful when you need an exact reading, and not the historical perspective that the graph provides. You can also see more readings in a table format than a graph format.
Tables and graphs created from a query are handled differently. The query creates a data structure, holding information about how to display and what to display. The object is created with this data structure, providing a more flexible graph format.
Map windows require a lot of pre-existing data for their use. The user must have created and specified a GPSGPS file in the options dialog, such as that generated by Sokkia's GPS software. The process of creating this file was described earlier in this thesis.
There are two types of maps that can be displayed with this data. One is an overhead view of the path saved in the GPS file, and the other is a side view. The overhead view is good for seeing upcoming turns, and it is in an x-y format. The side view shows upcoming hills, in a distance vs. elevation format.
Program options are handled through a class called TOptionsDlg. This class is derived from TDialog, and when created as an object will pop up a dialog with all of the programs options. Most of the program options are saved in the user's NT registry database. The registry database is a part of NT and Windows 95 that allows several users to have their own program settings, along with settings common to the whole computer. It is indexed for fast access, and accessible by system API calls. The Windows NT™ version includes optional security for registry settings. The registry is an improvement over Windows .ini files, and UNIX's .setup files.
The options dialog box also allows the user to set several warning conditions.
If conditions like excess current, or overheating of the motor occur, the
user of the program is notified immediately by a status bar message or
a message in the TAlert window.
Every non-queried graph that is created is passed a TGraphFunction object. This object feeds the data to the graph window. When creating the function object, the program specifies a data parameter. This parameter is either an element of the data packet, or a special code which tells the data handler to perform calculations on the data. This allows graphing of calculations to be done just as easily as a plain data element.
The TRegistry class retrieves and stores information into the registry database. The object automatically creates a section for solar car power management in the user's individual registry. Different users can set program options independently from each other. TRegistry is easy to use for the programmer. All the programmer has to do is set a value for a string-identifier, or retrieve a value for the identifier. For instance, the program could set "Window color" to "red", and fetch this value whenever it creates a window.
The THandleCarData class handles the car packet data sent over the radio modem. Every time a new packet is received, it is added through the AppendPacket member. Memory for storing the data packets is allocated in blocks. Each block holds 100 car data packets, the exact amount of which can be changed using the BLOCK_SIZE macro. To keep track of these blocks, the program has an array of pointers which can be empty, set to a memory location, or set to a disk reference. It would be a simple matter to cache the blocks to disk to use less memory, but since Windows NTWindows NT™ does this automatically I did not bother incorporating this into the program.
Searching for a data packet is done by its time-stamp. The first packet of each block is examined, until we determine which block the data packet is in. Then the program iterates through the block until it reaches a packet with that time stamp, or a time just after it. This is just a primitive jump-search algorithm, but it performs well enough make a more complex one unwarranted. This is because when the program retrieves data it usually performs just one search, and then pulls the data out in a sequential fashion (graphs and power estimation calculations, for example). So a complex indexing scheme is not needed.
Each computer analyzing the solar car data uses its own database of information. If that process crashes, it may be restarted using the same database. Multi-user access around a central database would not be difficult to add, but considering how often the disk drives were corrupted from power surges and excessive heat during the race, I felt maintaining separate copies would be wise.
The data is stored on disk in the same format that it is in memory. If this application were to be ported to an architecture where the processor byte-ordering for integers was different than Intel's, it would be necessary to add extra code to adjust the manner in which the numbers were saved and retrieved. For this reason, simply recompiling the power management software on a different Windows NTWindows NT™ platform, such as MIPS, Alpha, or PowerPC would not be possible without the above modifications.