[Solved] e.Appointment empty on second databind?

[Michel]

Hi,

It looks like e.Appointment is empty when you bind the scheduler for the second time. The following code is heavily simplified, but it does show the problem:

protected void Page_Load(object sender, EventArgs e)
{
  if (!this.IsPostBack)
    this.BindAppointmentData(); // first databind
}

private void BindAppointmentData()
{
  //database SELECT query is done here, a dataset is the result
  this.RadScheduler1.DataSource = {the dataset};
}

protected void RadScheduler1_AppointmentInsert(object sender, Telerik.Web.UI.SchedulerCancelEventArgs e)
{
  //database INSERT query is done here, new record is physically saved to database
  this.BindAppointmentData(); //second databind
}

protected void RadScheduler1_AppointmentDataBound(object sender, Telerik.Web.UI.SchedulerEventArgs e)
{
  // e.Appointment is filled here on the first databind, but empty on the second
  //here, i manipulate some properties of e.Appointment (subject and tooltip)
}

Am I missing something or is it a bug?

Thanks,
Michel

[Peter]

Hello Michel,

Please, follow the approach used in the  Binding To Generic List example. If you have further questions, please feel free to contact us.


All the best,
Peter
the Telerik team

Instantly find answers to your questions at the new Telerik Support Center

[Michel]

Hi Peter,

Thanks, but the problem also exists when using the approach from the given example. There's actually not much difference between my approach and the example - I don't like the example's use of session variables, but that is another story.

I've played around some more and I must admit I didn't describe the problem very well. This is the situation to reproduce:

1) You bind a custom collection, dataset, whatever, to the scheduler. You can use the given example.
2) You use the AppointmentDataBound event handler to override an appointment's property values (add it to the given example).
3) You use the AppointmentInsert event handler to manually add an appointment to your custom data source.

 Now, when you add an appointment, after inserting, the AppointmentDataBound is fired (don't know why). Within this event, the e.Appointment instance is available, but its "ID" property is not set. The "Start" and "End" properties are ("Subject" too, I assume). When you rebind the data source afterwards, all appointments, including the new one, are correctly loaded (this is logical). You can work around this issue by doing the following:

protected void RadScheduler1_AppointmentDataBound(object sender, Telerik.Web.UI.SchedulerEventArgs e)
{
  if (e.Appointment.ID != null) // this is true after inserting a new record.
  {
    // handle event.
  }
}

I hope I explained it well. You can reproduce the problem by using your own example, adding the AppointmentDataBound handler as I described, and then add an appointment. Check for "null-ness" of e.Appointment.ID. The problem seems to be the fact that AppointmentDataBound is fired after the insert. Why is this?

Thanks,
Michel

[Peter]

Hi Michel,

This is expected - the AppointmentDataBound event should fire after you insert an appointment. In a more regular scenario this is required so that you could immediately see the appointment in the scheduler after you insert it.

I am not sure why you find this problematic. What is the final goal that you want to achieve?


Kind regards,
Peter
the Telerik team

Instantly find answers to your questions at the new Telerik Support Center

[Michel]

Hi Peter,

I really don't want to keep repeating the same thing over and over again, so let's just leave it at this. Apparently, RadScheduler was designed with a very specific way of binding data to it in mind. Although I don't find my method very "irregular", I now know how to work around the problem (like I already demonstrated - the "null check"), so it's not really very problematic anymore.

I do suggest that telerik's developers keep an open mind for more advanced / custom / low-level programming scenarios. Personally, I find ObjectDataSource one of the biggest horrors ever, but that's an entirely different story...

Thanks for your help,
Michel