If you use the mousedown event, the x and y coordinates available in the
mouseeventargs are relative to the control.  Because the mousedown event
happens after the datechanged event, you have to do a workaround to
effectively reverse the order.  

I know this may seem a crude way to go about it, but if you create a timer
(form level, withevents).  Set the timer's duration for 100ms in the
Form_Load event.
Create an event handler for Timer_Tick.

Create a form level variable that will hold your DateRangeEventArgs until
the timer fires...Private DateRangeEventArgs as DateRangeEventArgs.  That way
the timer's tick event handler can act as a delayed proxy for your
DateChanged event handler.  Just port the code over.

After you stash the DateRangeEventArgs, Start the timer in the date changed
event handler.  During the 100ms while the Timer is waiting to fire, the
mousedown event will fire and there you can stash the MouseEventArgs in a
form level variable.  The MouseEventArgs contains your mouse X and Y
coordinates relative to the control.  

In the timer_tick event handler, stop the timer, and then do your tests:  
the two addmonth tests, as mentioned in previous message, and if either of
those are true, test if Me.MouseEventArgs.Y is less than 24 (or whatever your
click testing indicates...actually you could fudge it to allow a few extra
hundredths and be safe).  If the user uses the keyboard arrow keys, instead
of the mouse, to change dates, there will be no mousedown event, and
therefore no MouseEventArgs...handle that as needed.

Lastly, in the timer routine, reset your applicable formwide variables to
their wait-state values...
Me.MouseEventArgs = Nothing, Me.DateRangeEventArgs = Nothing

You may want to adjust the timer's interval, but I think 100ms should be
good.  You may be able to take it down to 50 or so.  I have tried using a new
Thread for this kind of workaround, but I find the Timer to be more
predictable and reliable.