charting/reporting app nearing completion

The combined charting/reporting app I am working on is nearly done, barring standard error-checking procedures to 'idiot-proof' the software (noone better to try that on than myself...). What it does so far is:

1. on first-time run, the user has to enter their aavso header details to make sure the observation file is in an acceptable format. This is a one-time only task but the generated file is a simple .txt file which can be edited if necessary.
2. On running, the user is presented with two options: either administer the starcharts database (which is automatically created at stage 1 above, along with a folder in which your charts MUST be put, or: go to the charting/reporting screen. Features of the DB screen are:
   a) Add a new record to the charts DB
   b) Search for a star in order to see its details or edit/delete its record
   c) View all your observations. The starcharts DB consists of 2 tables, viz: charts / observations. The observations table is populated as each observation is made and is ordered according to observation date/time.
   d) View observations of a selected star (i.e., see all obs of CH Cyg)
3. The charts screen can be seen in the attached screenshot and starts with a dropdown box listing all constellations. Clicking on a constellation populates a second DD box with all those variables in that constellation that the user has in their DB. Clicking on a star in that DD box puts that star's details (name, chart ID, current date and time) into text boxes. Hitting the 'get chart' button then displays the chart on the LH half of the screen. The chart is zoomable. Then you can enter your estimate, comp stars used and any notes.
4. Hitting the enter button writes the observation record to both the AAVSO-format file and to the observations table in the DB. When the screen loads initially, the user-generated header is written to the top of the file, which is automatically named after the date it was created. All files are written to a dedicated folder so the user always knows where to look; and since the app is DB-based, the user always has the latest version of the file should a power outage or other disaster occur.

I am in the process of writing a simple help file in the form of an HTML page (which MUST be read first as it details the naming format for your chart files. A standardised form for these proved necessary since the app relies on this format to search for charts in the DB) - because if the app is going to be used by a wide variety of folks a one-size-fits-all approach is unavoidable. Sorry!

Attached screenshot shows an observation entered, with the chart zoomed in. Note the file name is shown in the window's title bar. I thought it best to have a night vision-friendly screen colour!