This question is locked. New answers and comments are not allowed.
See the attached screen shots. They are taken in your Context Menu Integration example.
This bug does not affect the standard functionality of the ScheduleView, but in our scenario it makes a huge difference. In fact it breaks it completely. I will explain:
Note that this bug occurs also when double clicking to create a new event.
I guess we might be able to hack our way around this, but this is clearly a bug. It was not present in the previous version and we would prefer that it was fixed. We need a fix within a few weeks, so I am hoping that you can squeeze this into an internal build.
Best regards,
/Henrik
- Screen shot 1 - I am creating an appointment in a slot I pre-selected. No other appointments exist in the current view. You can see that the slot is selected in the background.
- Screen shot 2 - I have now selected a slot and opened the context menu. The slot is still selected behind the context menu.
- Screen shot 3 - Now I have clicked "New Appointment" in the context menu. As you can see, the slot is no longer selected.
This bug does not affect the standard functionality of the ScheduleView, but in our scenario it makes a huge difference. In fact it breaks it completely. I will explain:
- When the AppointmentCreating event is fired we cancel it immediately and present the user with a window where he/she can select the type of event to be created.
- When the type has been selected, we make a service call to get an entity for the new appointment, populated with a bunch of default values and such.
- When the entity comes back we execute the CreateAppointmentCommand manually.
- The AppointmentCreating event is now fired again. This time we populate e.Appointment with values that we got from the service call. We also populate the Start and End properties with the values from the SelectedSlot. And here is the problem. If other appointments exist in the view, the SelectedSlot is null and we cannot use i, which means that the appointment will be created at the wrong time.
Note that this bug occurs also when double clicking to create a new event.
I guess we might be able to hack our way around this, but this is clearly a bug. It was not present in the previous version and we would prefer that it was fixed. We need a fix within a few weeks, so I am hoping that you can squeeze this into an internal build.
Best regards,
/Henrik