I need to track a subregion of individual Days in a Month or MonthRange view and respond to user interaction such as mouse events.
If we could call a method to retrieve DayContent element bounds in screen or client terms by index (DateTime would make sense), that would be great, or if there is a better way to make the cells "active" let us know.  It may also be helpful to get the location index (row x column) of the square in the Month(Range) grid.  I looked at the other posting about items and controls embedded which was very helpful, but this seems to apply only to Timetables.

Also, the Bounds passed in the Draw event args are incorrect for DayContents and we are unable to translate them to Client coordinates as is thus the request above.  For example, if the DayContents are in a 100x100 rectangle, the height will be 0 but the Y value will be 100. We have figured out that the Y is actually 0 relative to the day cell (contents) being drawn but the height should be 100, so we have a helper method translate the bounds.  Is this expected?

Thanks in advance yet again.  This control is great.

Ok, thanks & let us when the new parameter for GetElementBounds is available for testing.

It sounds like we may need to ask you to add CalendarElement.DayHeader to the options for the control.  I tried setting Calendar.MonthSettings.DaySettings.HeaderSize to greater than 0 in a recent build which appeared to have DayContents option in GetElementBounds, but I always got an empty rectangle back for the contents.  In other words I tried to force it to use DayContents by setting the header as suggested but was unable to get the bounds (and the Contents still has 0 height).

Meppy,

Sorry I should have written more clearly.  I was expecting that you would add CalendarElement.DayContents as an enumeration member on the element option of GetElementBounds.  So I was trying to say we might also need CalendarElement.DayHeader depending on if we use day headers or not.  However it looks like you've added the whole DayCell, which is great.  We can always split that ourselves into Header and Contents rectangles in client coordinates using the DayCell bounds plus the header height, if any.

I've tested the download and it looks like I'm not getting any bounds for cells other than the first (index==0).  I added some console writelines capturing draw on DayContents and DayHeader but I've never seen the other cells's bounds and always get the same location (x, y):

void calendar1_Draw(object sender, MindFusion.Scheduling.WinForms.CustomDrawArgs e)
       {
           Rectangle drawingBounds = Rectangle.Empty;
           switch (e.Element)
           {
               case MindFusion.Scheduling.WinForms.CustomDrawElements.DayHeader:
               case MindFusion.Scheduling.WinForms.CustomDrawElements.DayContents:
                   drawingBounds = calendar1.GetElementBounds(MindFusion.Scheduling.WinForms.CalendarElement.DayCel
l, e.Index);
                   break;
               default:
                   return;
           }

           if (drawingBounds != Rectangle.Empty)
           {
               Console.WriteLine(string.Format("Item index:{0}, bounds:{1}", e.Index.ToString(), drawingBounds.ToString()));
           }
       }

What we are trying to do is update the screen outside of Paint (Draw) events, and add some other interactive features that use hit testing inside certain areas of the bounding rect.  This is why we need the client coordinates, so we can use the correct coordinates (or translate to screen to draw to device context) if needed.

I tried to use Invalidate(rectangle) with Update with the Control but the Draw events only seem to fire if you invalidate the whole control with its children Invalidate(true)...This may be because of confusion on my part about which coordinate system to use, or because I need to handle Invalidate instead of Draw - but if the latter I need to know the non-internal [e.g. client or screen] coordinates of the area, don't I?

Definitely inside a Draw event you only need the Bounds in the args to use that particular surface.  However for some situations (as mentioned above) we require different information.  For example one of the components we are using to change interaction is based on screen system.  For example, if you mouse over a certain part of the Day Cell this component changes state, and responds to events such as clicks.  Since we cannot imbed a control inside the cell "directly" we are trying to get the coordinates in more "absolute" screen or client terms in order to process these messages/events/et al.

How would you recommend we do this for days in a Month if not with GetElementBounds which I agree may not be the best candidate since it doesn't use an index which makes clear sense for Month view?  I was thinking a method to get DayCell by date index could be added, but I realize this might be something more difficult/time consuming for you guys to develop.  If there is already a better way I'm of course open to suggestion.

Hi Charliemouse,

The Graphics property of the CustomDrawArgs class has been pretranslated before the event handler is invoked. That's why the Bounds property looks identical for each cell. Drawing within this bounds using the supplied graphics will paint exactly within the appropriate cell.

In order to check which location the current cell is in within the Calendar.Draw event handler, you have to inspect the Resource property of the event args object. It contains a reference to the related Location, Resource, Task or Contact (depending on the current GroupType).

If you make an application similar to the Drag & Drop sample, there is a place in the DragOver event handler, where the date under the cursor is obtained (in order to be subsequently custom-painted) through a call to the Calendar.GetDateAt method. If you are using a groupped view, however, you may also have to obtain a reference to the resource associated with the pointed date, by calling Calendar.GetResource method.

I hope this helps.

Meppy

Thanks Meppy.

I know I checked the resource value and it was returning null, but now I try it again it works fine - must have been dreaming.