Odd behaviour of AppointmentEditorOpening Event in SFSchedule

[Holger Schade]

Hi,

I am trying to set up a SFSchedule control with a custom AppointmentEditor. For this I am using the code provided in the SFSChedule customization sample. There it says that the  AppointmentEditorOpening Event should be intercepted and the e.cancel property should be set to false. The code works, except for the following fact. Once the code e.Cancel=false is executed it sems that  some SFSchedule objects or threads are not cleaned up properly. To reproduce try to do the following:

• Start the Sample Dashboard -> WPF -> Schedule ->CustomizationDemo in Visual Studio 2013  Debugger (specifically I was Opening the CustomizationDemo_2013.sln in Visual Studio 2013 and then I Start Debugging)

• Open the AppointmentEditor, then Close the Appointment Editor then Close the MainWindow. Once closing the MainWindow the Application should stop debugging, but it does not, You need to shutdown the debugging session manually.
  

Can you explain why this is happening?

Another side note on the SFSchedule control: As the above method did not work for me (I felt uncomfortable that not everything was cleaned up properly), I was trying to use the ScheduleDoubleClick event instead. However this event never fires. The ScheduleClick event however does fire.  Can you tell me under which conditions the ScheduleDoubleClick event fires?

[Vigneshkumar Ramasamy]

Hi Holger,

Sorry for the inconvenience caused.

Regarding”Debugging does not shutdown after closing SfSchedule application”

We are able to reproduce the mentioned issue of “Debugging does not shutdown after closing SfSchedule application “and we have logged an issue report on this. The fix for this reported issue will be available in our upcoming main release which is expected by the end of this month. We appreciate your patience until then.

Regarding”ScheduleDoubleClick event doest not fire”

We are not able to reproduce the mentioned issue of “ScheduleDoubleClick event does not fire” . Could you please provide us simple sample to replicate your scenario to get this error? So that it will be very helpful for us to analyze on it and provide you the possible solution.

Please let us know if you have any concerns.

Regards,

Vigneshkumar R

[Holger Schade]

Hello

for a reproducable simple case to show that the ScheduleDoubleClick event does not work  I attached a Visual Studio 2013 Project. I hope that this helps!

[Vigneshkumar Ramasamy]

Hi Holger,

We cannot find the attachment in the previous update. Could you please check and update with the replicating sample. If possible could you please modify the below sample to reproduce the issue. So that we can analyze further and provide you a possible solution. 

Please find the sample in the below link.

Sample Link:  SfSchedule_DoubleClickEvent.zip

Please let us know if you have any concerns.

Regards,

Vigneshkumar R

[Holger Schade]

Dear Vigneshkumar Ramasamy,

I actually used your sample and it did work. The only difference between your sample and my sample is, that you are doing it with the .NET 4.5.1 Version DLLs and I did it with the Version 4.5.0 DLLs. With the 4.5.0 DLLs I still have the problems.  Otherwise the samples are identical.

So I will switch to 4.5.1.

Thanks for your help :-)

[Holger Schade]

Dear Vigneshkumar Ramasamy,

actually now I found the Problem with the ScheduleDoubleClick event. The Event will not fire if you set the AllowEditing Property of the SFSchedule to false. I personally think that this behaviour is not correct. If the AllowEditing Property is set to false I would expect that the Appointment Editor should not be opened, but the event should be triggered.

Regards

Holger

[Vigneshkumar Ramasamy]

Hi Holger

Sorry for the inconvenience caused.

Regarding” The Event will not fire if you set the AllowEditing Property of the SFSchedule to false”

We are able to reproduce the mentioned issue ” Editor opening Event is not fire on setting the AllowEditing Property of the SFSchedule to false” and we have logged an issue report on this. The fix for this reported issue will be available in our upcoming main release Vol 1, 2015 which is expected to be rolled out in the end of this month. We appreciate your patience until then.

Please let us know if you require further assistance on this.

Regards,

Vigneshkumar R