Reminders: Strategy For Seeding Dates?

[(PeteCresswell)]

I'm writing an app that does reminders.

When creating a new reminder, the first thing I do is solicit
some info from the user and then spawn a series of reminder dates
depending on that information.

The pieces I need are:
-----------------------------------------------------------------
- Repetition type (single, monthly on first of month, monthly on
last of month, monthly on n-th day of month.... quarterly...
weekly, yearly....)

- Number of repetitions desired

- Year that the repetitions begin

- Week or month, or quarter that the repetitions begin

- (in the case of one of the n-th day options) the ocurrance of
the first repetition within the period (workday within week,
month within year, quarter within year...
------------------------------------------------------------------

There's more, but you get the idea.


Right now, the user chooses the repetition type and then slogs
through various choices as I progressively reveal combo boxes and
text boxes depending on the type.


My question is this: has anybody been here and done this more
elegantly than just forcing the user to slog through the choices.

I'm thinking maybe some creative use of the calendar control
instead of all those visible/invisible combo boxes for starting
day/week/month/quarter/year...

 

[IRS Intern]

yeah you are reinventing the wheel

you should use SQL Server / SQL Agent to write all your reminders for
you, it would be super easy

 

[Allen Browne]

Pete, if you have Outlook installed, open the dialog for a new recurring
appointment. (It's on the Action menu when viewing the calendar.) That
should give you a suggestion on how it might be interfaced.

As far as the data storage goes, there are several issues to address here. A
fairly simple approach is to store the recurrence in 2 fields:
Frequency Number (Long Integer)
Period Text (4 char)
Use a combo for the Period. The combo's bound column contains valid options
to use with DateAdd(), e.g. d, m, q, yyyy. You then use a counter table, and
create a query with a Cartesian product to give you all the recurrences as
the calculated field:
DueDate: DateAdd([CountID] * [Frequency], [Period], [StartDate])

The next level of complexity involves storing exceptions (e.g. where one
meeting in a sequence gets canceled or rescheduled to a different date.) If
you ultimately need to store all occurances, there are issues with those
items that have no end date. Then there's the issue of things like vehicle
services that don't occur on the exact date but are due "3 months from the
last one" yet you still need to be able to predict when the entire sequence
is likely to be based on the most recent one (so using the Cartesian product
again.)

Hope that gives you some useful leads to consider.

 

[(PeteCresswell)]

Per Allen Browne:

The next level of complexity involves storing exceptions (e.g. where one
meeting in a sequence gets canceled or rescheduled to a different date.) If
you ultimately need to store all occurances, there are issues with those
items that have no end date. Then there's the issue of things like vehicle
services that don't occur on the exact date but are due "3 months from the
last one" yet you still need to be able to predict when the entire sequence
is likely to be based on the most recent one (so using the Cartesian product
again.)

Hope that gives you some useful leads to consider.

FWIW, I used to have this taped to the corner of my monitor:
--------------------------------
The important things are simple.

The simple things are hard.

The easy path is mined.