Another extremely frustrating problem with what seems to be a not very well thought out event system.
I need an answer to this basic question; How can i allow users to move appointments between owners, while preventing them from moving the appointment up and down the timeslots (they should be allowed to change the owner, but not allowed to change the start and end time). The answer is you cant, unless you perform some hideous workaround like reverting the appointment back in the AfterAppointmentsMoved event if the timeslot changes.
If i knew where the appointment was being moved to, i could use the eventargs.Cancel property to stop them under certain circumstances and it would be a very clean and tidy solution. But since the event args do not provide us with any information about where the appointment is being dragged to, it actually provides little value at all.
The lack of common sense when it comes to these events has caused me huge headaches in the past. Another prime example is the BeforeAppointmentResized problem i mentioned in my previous post. It drives me insane.
You can tell me to log an enhancement request, but ive already done that. These issues have caused me problems in the past because the workarounds for basic missing functionality mean im forced to write ugly and unreliable blocks of code to work around it, and i have logged requests to have these issues sorted but 2 or 3 major versions later its all still the same.
Four new events will be added with the NetAdvantage 2009.1 release: AppointmentsResizing, AppointmentsResized, AppointmentsDragging, and AppointmentsDragDrop. The motivation behind these new additions was primarily the limitations you mentioned herein. The associated event arguments classes for the "ing" events expose a 'Phase' property, which tells you whether the operation is beginning, in progress, or ending. The "ing" events are also cancelable.
I'm not certain that you will be able to accomplish your goal of preventing changes to the dates while still allowing changes in ownership (to my knowledge this is the first request for such functionality), but they do provide more flexibility than the events that existed in previous versions.
This is great news - those events sound like they will provide us with a much easier time with development!
Most of the time, you would only use the cancel property to cancel a drag event if they are dragging it into an area you dont want them to. So basically, the drag events should provide the user with information about where they are being dragged to (updating the appointment owner/start/end time before these events are fired would be sufficient, because the developer could store the previous location information into variables before the drag operation starts) - otherwise the cancel propery serves no real purpose because otherwise you would just set the appointment to Locked.
If my above statement is true, then i should be able to accomplish my goal of moving an appointment to another owner but not another timeslot. The key here is being able to know where the appointments are being moved/resized to. If i know that, then i can just use the cancel propery of the events to cancel operations i dont want.