Gary,

You might consider something like this:

1. Initialize your date to the current date. If the user wants to enter a specific date, so be it, and you're done. If not...

2. Use the KeyPress event to trap for the ALT key + plus sign to mean +1M or ALT key + minus sign to mean -1M and CTRL key + plus sign to mean +1Y and CTRL key + minus sign to mean -1Y. (I think you'll find that '+' and '-' when used in the textbox will already increment/decrement the date by 1 day too.) Then based on the key combination, update the value of the date control. If users need a visual clue to help them see how many months or years they've approximated, you could show that as a label to the right of the textbox.

Another approach might be trapping in the KeyPress for some special key combination that signifies to the control to pop up an approximation window that lets them enter the offset in months/years and if they accept, return to the original control and update its value - otherwise no change.

HTH,
Scott

>All,
>
>I have a requirement for a text box to offer some additional date based functionality. My users have requested the ability to enter an "approximate" date. The reason for this is because at the data entry stage, when they ask the customer for a date, often the answer is "10 years ago" or "18 months ago". So, instead of working out the exact date, they would like to enter a "-18M" or "-10Y" type of value and have a date value returned that represents the offset.
>
>I have built some logic into the Keypress and Valid events that handles this situation but, the data entry looks clumsy to me. I have thought of a control class with multiple controls, maybe a text box, spinner and dropdown list (containing "Month", "Years" values) and something to signify whether we are going backward or forward in time.
>
>Also, this requirement is in a "heads down" data entry situation so, leaving the keyboard for the mouse is not particularly desireable.
>
>If the user enters no value in the text box and given that this is a "must complete" field, then this would be a signal to the custom logic that an approximate date needs to be entered/provided. After this, we need to quickly arrive at the decision as to whether we are going backward or forwards in time, the number of units (months/years) and the time unit itself (months or years).
>
>Any thoughts as to how to achieve this in a professional and polished manner <s>?
>
>Many thanks for any/all suggestions.