It does not make sense to me that you tell me that the slot should be able to contain at least one appointment. If the user choose 9 fields to display and this produced 150 px appointment height and it does not fit in the 85 pix row hight then the appointment should not be visible. That's the only way setting a custom Min Appointment Height can work in all cases. This will also leave room for the ExpandToggleButton at the bottom as the button is 13 pixels height and much of the time if not all the time, the week slot will be at least 13 pixel height.
I cannot tell the user that he or she need to choose only a set of fields that will produce an appointment height that is less than the week slot height and to make sure he or she also leave space for the toggle button at the bottom. There are around 30+ fields in our application the user can pick and choose to be displayed. What needs to work is the measuring logic with any appointment height.
Just tweaking the GroupHeaders is not going to fix the resizing problem in the layout of the appointments nor is going to be that helpful if the user choose for example to display 20 fields that produce 400 logical pixel height appointments.
Sofware needs to adjust to satifsfy the user requirements instead of the user adjusting to the sofware limitations.
As I said on my first message, if you set the pixel height to 150 for any of the examples you will see that there is a problem with the sizing logic. If you support the ability to set a "MinAppointmentHeight", then the measuring and sizing logic should work with any arbitrary appointment height you choose.
Here is another screen shot attached. On this second screen shot you can see that now the week row height is greater than a single appointment height. However, we still have the same problem of the second appointment overflowing the boundaries of the week slot. The reason for this is obviously that the measuring logic is failing to properly measure the appointments height now that there is a "MinAppointmentHeight" being set.
What you suggest is :
1- A slot should be able to contain at least appointment.
2- There should be enough space for the Toggle button to be visible.
The requirement above are artificial, there is not technical reason that it needs to be that way.
I do understand that the sizing logic is not "Auto". The current logic is this:
1- Display as many appointments as they possible fit in the week slot.
2- Appointments that do not fit should not be visible.
3- When measuring how many appointment should be visisible, take into account the toggle button height too.
4- If all appointment for the week slot are visible, then the toggle button should not be visible.
I want the same exact logic to be applied when I set the "MinAppointmentHeight" to 150 pixels.
For my first screen shot, no appointment will be displayed since the 150 pixel height appointment does not fit in the 85 pixel height week slot. The toggle button should be displayed to still give the user the ability to expand all of the appointments.
For my second screen shot, the first appointment should be displayed but the rest of the appointments should be non visible. The toggle button should be visible.
This would work for any arbitrary value of the "MinAppointmentHeight" as it shoud be, without any artificial or arbitrary limitation imposed on the user.
The bottom line reason why this not working is because the logic in the "AppointmentsPanel" control specifically the "MesasureOverride" method --I use Reflector to trace where the visibility of the appointments is set on and off- is not properly calculating the appointments height. The caculation of the appointments height is buggy. If you fix that, this problem I am having will go away.
You do support a property called "MinAppointmentHeight" and setting the value of this property to arbitrary values should work on the context of displaying the appointments and the toggle button, just as it does with the default template of just displaying the "Subject" of the appointments. You cannot have a "MinAppointmentHeight" and then tell me about artificial limitations that I cannot possible ask the end user to honor.
I had your code base, I would just go a fix the problem where I indicated above. I have a strong feeling that the logic for measuring the appointments is probably failing because there is a line there that is not taking into account the current "MinAppointmentHeight" but is still stuck using the height of the default template that just uses the subject of the appointments to calculate the height. Once that is fixed, setting the "MinAppointmentHeight to any arbitrary values would work with all of your sample as well as on my application without any artificial limitations. Would not that be great?