Brace yourselves :)

AusMarkB

Experimenting with the calendar control so some questions to come but the first I want to address is....
Is there a recommended use case for the apptChanged event?
I want to apply some logic when the user moves an appointment and trying to decide on what the best practice would be.
I'm thinking that I don't want to do too much because the event fires for every movement rather than just the release.

I figured that's ok, I'll just keep tabs of which appts are being moved and have a save/apply button for the user to lock in all their changes.
However, I also thought I could at least change something about the appearance of the appointment so the user would be able to easily recognise what they've already moved.

And that's where I hit a snag. If I set a property for the appointment, the appointment is returned to it's starting position.
Eg: The user moves an appointment from Thursday to Friday. I change the ApptBusyStatus to "Tentative", the visual changes take place but the appointment gets set back to Thursday. Same thing if I change ApptIsMeeting. I haven't tried every property but I'm thinking this aint the way it's meant to be.

KevinFournier

The Calendar control was added because we had folks trying to use the Schedule control as a calendar. They were running into a lot of problems because a calendar is a slightly different metaphor to a scheduler. We are using the calendar control developed by CodeJock. It was designed to emulate the Outlook calendar, and nothing more.

I think this is why you are struggling to make the calendar more dynamic. It's designed to allow the user to make changes at their own discretion. Things like ApptBusyStatus and ApptIsPrivate are not meant to be automated, which is why they are failing when you set them during a drag. I tried to work around this, but so far without success.

If I find a way to let you dynamically change appointments during a drag, I'll let you know. In the meantime, I'd argue that the user should be choosing the appointment's state, not the software.

AusMarkB

We're trying to let the users make changes at their own discretion, eg move an appointment.
The problem with that is, we don't know when they've finished moving it.
You could argue, they change the appointment and we retrieve the new start/end datetimes and save them away.
Except the only event is onApptChange, which fires for every variation to the existing appointment, so the same event could fire multiple times for the one movement/drag and that's overkill for getting properties and writing it away.

Hence, I figured if I could just change something subtle but visual, then the user can "Save" the change/s at their discretion. And there's no problem in making that change, the dynamic change to the state works and the appearance changes but you release the mouse and the appointment jumps back to where you dragged it from.

I've played a little with the calendar before but came away thinking it was a little undercooked. It looks good and I like it but it feels like either I'm missing something or it offers/suggests features you can't really make use of.
I could theoretically set it up with a ribbon type look and rely on the selection property and ribbon buttons to do things but I think two things in particular are just a little more intuitive.

1. Dragging the appointment to change dates/times should be able to be captured effectively on the drop and
   
2. A click/dblclick event so you can open the appointment details or add a context menu so you can make state changes if you wish.
   

I feel like those two things alone would change the calendar from something that looks nice to a very useful tool.
Of course, I could have my blinkers on and others may have put this to use with great effect. I assume you guys have somewhere.

Granted, we'll probably end up changing to the scheduler but I also started on that last night to have a look and it created it's own issues including regularly crashing OI. I'll dig into that a little more myself before I throw on here though.

KevinFournier

I agree that it is undercooked. It gets far less attention than our other controls. For what it's worth, I did spend a few hours last week trying to make it work as you expected, without success. There's probably a way, but it would require refactoring the source code of the third party control it's based on. It seems, however, that given your use case, the Schedule control might be the better path for you anyway. The Calendar is designed to plan out a single person's itinerary. The Schedule control is designed to manage resources across multiple entities.

AusMarkB

Appreciate the effort Kevin.
TBH, I'm not convinced there's any control that really fits the bill as more client requirements come to hand, but the scheduler is the one that seems to offer the closest fit.

We'll push forward with that.