>>>Ahh, the problems of multiple controls. I use the MS Monthview control that does have the 3 properties exposed at the control level and the Values property at the .Object level. I should have been more specific. Thanks.
>>>
>>Mark,
>>
>>The Monthview is OK, but really rather inappropriate for this project. That's why I'm using the Calendar.
>
>Hmmm, I have a test form where I put both controls on it. I don't see offhand what the difference is other than UI. However, I am using Calendar Control v7 [MSCAL.Calendar.7]. From the command window, all the following do exactly the same thing:
>
>Test.oleMonthView.Object.Value = {somedate} && date changes
>Test.oleCalendar.Object.Value = {somedate} && date changes
>Test.oleMonthView.Month = 6 && month changes to June
>Test.oleCalendar.Month = 6 && month changes to June
>
>Maybe Calendar.8 is different?

Sure, the above should work fine with Calendar.8. But try dropping one of the combos and changing the month or year. Then,

Test.oleCalendar.Day = 6

and see what happens. It could also be that the order that I was assigning the values had something to do with it too. I'll have to check that. There's also another problem. There's no easy way to get the value the user selects in one of the combos. Of course, there's a way, but that's going to be the subject of a VFUG article.< g >

>>Basically, the circumstances that cause this (for any lurkers) occurs when the user selects a month or year from one of the combo boxes. What happens is that the .Value, .Month, .Day, and .Year properties are all set to empty. If you do not set the .Value property first, the others won't take. Rather disconcerting to be stepping through the code in the Trace window, seeing the a variable with a valid value, assigned to one of these properties and then see them unchanged. I understand why this happens, just wasn't aware that it did.