AguaClara design tool code development guide
The AguaClara design tool is in proof of concept form. In order to run the program the user must use internet explorer and must download and install LabVIEW Runtimes 8.2.1. The software will allow multiple user to run the design tool because I have set the code to be reentrant. The design tool is available for testing purposes.
User account management
Do users sign on and create an account with a password or do we simply use their email address as the unique identifier? Using email addresses would eliminate the need to verify uniqueness (although someone could access someone else's files if they know their email address.) This would require that we save a table of email addresses and the unique IDs that go with them. Then we need the ability to search through the list of email addresses and look up the ID. Perhaps keep an array with a cluster of email address and unique IDs.
We could give each project an ID (the time stamp when the project was created). Either this could be part of the file name or it could be a folder. Make the timestamp be a folder. Then when we display the list we can display the project creation date based on the folder name.
We need to make sure that if a user opens an old project and reruns the design algorithms that we don't allow saving the results over the previous files. This is important because we will change the design algorithms. Old designs must be kept as built. Thus the design command must only be available for new projects. The user could load an old project, then select new project (to get a new time stamp) and then the design command would be made available.
File structure
Project information
C:\Documents and Settings\All Users\Documents\DesignData\userid\timestamp\projectname.acp (AguaClara Project)
User database
C:\Documents and Settings\All Users\Documents\Userdatabase\user.acu (AguaClara User)
File name convention: ...DesignData\userid\timestamp projectname.ext
This implies that we need a different extension for each type of file that we store.
Users should be able to create, open, and delete designs. We could even display a list of projects in the folder for them to select from since we should not give the user access to a real file dialog box. (All emailed designs will be sent to the wiki and so we will have a second copy should the user decide to delete a copy.
The project info should be saved using the save anything code that I wrote, but must figure out how to handle data structure updates for backward compatibility
For now, the basis of design will remain in a MathCAD file.
We need the ability to switch languages. I imagine a file containing an array of object identifiers and the text that goes with those objects.
The program needs an initialization step where the AutoCAD and MathCAD references are established and the applications opened. We may need to figure out how to get MathCAD to open from commands from the web browser.
Code management
- Implement source forge control on LabVIEW code for this project. (also create folder on this computer that is linked with source forge to the MathCAD files)
- Learn how projects work in LabVIEW
- Learn how versions work in source forge and begin using this for the MathCAD design program.
User interface
- Create toolbar icons for each command that the user can execute
- Enforce program flow. For example the AutoCAD file won't exist until after the command is sent to AutoCAD. If the user tries to email the attachments before running AutoCAD the AutoCAD file won't yet exist. One possibility is to disable Booleans that shouldn't be used.
- Determine if dialog boxes work in the web environment. Dialog boxes could be used for confirmations of project deletions or for getting passwords if we use more sophisticated user accounts.
Program defaults
Program defaults are saved in an ini file.
- message sent along with email
- file path to saved projects
- file path to MathCAD file