Initial Notes (before commencing):

Stage 1

Stage 2

Stage 3

Memos about Optional Work

• support schedules (no contact support yet)
• design dialog for date setting for schedule (support no week, no day, etc). Dialog should have okay and cancel
• design dialog for date setting for pre-alarm (relative time to schedule), with okay and cancel.
• when alarm is set, also set next_alarm_date and next_alarm_time in the user's schedule_custom_settings.

• Support checking for valid alarms

• checking alarms:
• when the program is started, and thereafter once a minute, the program will check for any expired alarms (or pre-alarms) for any groups the user is a member of
• this might be done one of two ways:

• a SQL query that looks for any schedule older than the current time
• or if this doesn't work, store all alarmed schedules in a dynamic array and check the times in this every minute (could be sorted by time when program starts, so speedy binary searching could be used)

• If this last option used, should probably time stamp the database for the last time client scanned alarms. This timestamp can be checked every minute, just in case alarms have been changed on another computer. This allows for sending a message to another user. This timestamp should somehow identify the host computer (hostname??), so that more than one computer having the same user logged on don't re-query every time.

• start announcing valid alarms with proper dialogs:
• When an alarm time comes up, a dialog box should announce the alarm, giving the user the opportunity of snoozing, editing or cancelling the alarm. At this stage implement a disabled "view contact" button.
• Fix the snooze time in an init function for now, to be adjusted in settings later
• If the alarm is snoozed it is written in the user's custom settings table for that schedule (in the database).
• Pre-alarms should just have an okay button to acknowledge them

• multi-user support
• check for existance of user, and password request or not at startup
• show records only where user is member of group

• keep bookmark of last record succesfully viewed to return to if no more viewable records are found.

• include user changing dialog and menu entry
• support ownership of schedules and contacts

• support changing ownership
• if change will make invisible, warn user (or prohibit)?

• program settings dialog

• establish menu entry for properties (or settings?)
• bring up dialog with user settings
• The snooze time should be at least "globally" user adjustable.
• write the settings to an .ini file (as platform portable as possible)

• Implement entering contacts (no company support yet)
• Support onchange

• monitor all text fields on display
• check for "isDirty" before allowing window close, next/previous entry, etc

• Implement Company support
• implement company "slider". Allow choices:

• a company associated with current contact
• entering a company associated with no-one (a blank contact?? or program to display nothing if no contact associated, or special null or blank contact associated??)
• implement company selecting for association

• implement search facility:
• use query-based search for some text in schedules, the contacts, or both.
• searching might also be restricted to "my own private data", "shared data" or both

• implement online help:
• document program at the minimum with online help from a help menu
• preferably use help ids to enable context sensitive help throughout program
• Finish a pdf and html version of user manual for program

• implement installation program:
• build an installer program for at least the windows platform

(email me if you have a suggestion):

• Task bar applet
• try implementing alarm checking applet that launches program with the alarm checking code already written

• try applet for win 95 first (should Qt be considered for this part if it support applets under win9x and kde?)
• can some of this be ported to KDE and gnome?
• possibly write a menu clock type application for the Mac

• Port to ODBC Socket Server (or similar… to use across the internet)
• Try to port the wxwindows ODBC classes to use ODBC socket client software rather than the w9x built-in ODBC driver. If this can be done, this can become the basis for the "online" database access of softorganiser.
• Working Offline
• on accept changes to offline database, log changed field to offline change log.
• support secondary database stored locally. Can be platform dependant, as long as it takes SQL queries to create and update records, etc
• when switching to offline, always start with an empty database (for each record found in offline database, delete it), then copy every viewable record to the offline database. This could cost a bit of time for the user, but it simplifies things drastically for the developer (me)! It may not take any longer to do this, than it might to check for existing records, and changes to them, anyway. Another option, of course, is to have the offline database constantly shadow the online database, which could provide a handy redundancy (but if this is done, it should be switchable to save speed problems on large networks).
• Note that if the online database kept a log of all changes, the local computer could compare this to the local log and, if need be, update itself every minute, meaning the client could always use the local version of database. This could drastically speed things over slower internet connections.