Comments by Lisetsky Val (Top 6 by date)

Thanks for binging up problem with Adapters and ASP.NET Calendar - it was big surprise for me that it behaves like that.

This is forces me to dig this more.
Actually, congratulations! You found bug in ASP.NET Calendar :)

Here what it has inside for raising events:

protected virtual void RaisePostBackEvent(string eventArgument) {

ValidateEvent(UniqueID, eventArgument);

if (AdapterInternal != null) {
IPostBackEventHandler pbeh = AdapterInternal as IPostBackEventHandler;
if (pbeh != null) {
pbeh.RaisePostBackEvent(eventArgument);
}
} else {
...goes code that raises event if no Adapter assigned

What is it means?
If adapter assigned to Calendar - it MUST implement IPostBackEventHandler and MUST take all the responsibility for events raising. Since Adapter developer have no access to protected and private fields he cannot do this (and usually he dont know all the internal code tricks for calendar)

Correct code should be the following:

protected virtual void RaisePostBackEvent(string eventArgument) {

ValidateEvent(UniqueID, eventArgument);

IPostBackEventHandler pbeh = AdapterInternal as IPostBackEventHandler;
if (pbeh != null) {
pbeh.RaisePostBackEvent(eventArgument);
}
} else {
...goes code that raises event if no Adapter assigned

This will pass RaisePostBackEvent handling to Adapter ONLY IF it supports it. Otherwise it will do default handling.

So, bad news:
Any ControlAdapter that applied to Calendar should take care of raising events (stupid). You can check this by commenting all code in my adapter - calendar will still not work.

Possible solutions:
1) Inherit from Calendar and override ResolveAdapter method like this:
protected override ControlAdapter ResolveAdapter()
{
return null;
}
this code will drop off any adapters assigned to Calendar.
This new Calendar will work as expected.

2) Apply my Adapter to any controls you need EXCEPT Calendar (labels, hyperlinks and so on...)

Hope this helps :).
Summary for myself - never ever use this buggy control.

Calendar is IPostBackEventHandler. We cannot remove ID attribute for controls that trigger postbacks because their ID (UniqueID) is used on Client side. Just view source and you will see multiple lines.

javascript:__doPostBack('rep$ctl00$calendar','V4352')

They use UniqueId of calendar to do postbacks that will be understanded correctly by ASP.NET and raise corresponding events.

That's why Adapter in my code uses the following statement:

if (Control is Table || !(Control is IPostBackDataHandler || Control is IPostBackEventHandler))

It allows postback controls render correctly (with Client ID). Because they may not work without this.

My solution works well for simple controls like labels, hyperlinks and so on.
More complicated controls (postback controls) should live by ASP.NET rules.

So probably best solution for you is to look for more compact 3rd party calendar.

Reason for my vote of 5
Native solutions are always better than JS workarounds