EntityList/AppointmentList properties

AusMarkB

After setting the entitylist and appointmentlist properties is there any known issues with resetting either of them?
For example should either of them be reset to null or something before resetting them again or once appointmentlist has been set is it recommended to only use the add/remove appointments methods to modify this?

I just had some issues this morning whilst I was testing with OI crashing. I was resetting the both of these properties upon the selchanged event of a tab control. The values were basically the same each time, I was just making subtle changes to the code and then clicking the tab to update the schedule so I could see the effect of the change. After 3 or 4 or maybe half dozen sequential clicks the app would crash. :-( Sorry I can't be more specific, it was the early hours of the morning and I decided to go to bed instead of document. ;-)
I did get a windows message about the visual c++ runtime library or something and I took a screenshot but its on a different computer so I'll have to add it later if you'd like.

Not urgent for me but it seemed too dramatic to have not been noticed before. The last crash actually resulted in a multitude of windows messages on top of each other as if it was an endless loop except I'm not looping. Loopy maybe but looping no.

DonBakke

I am a few days late in answering this, but here it goes:

As far as the crash goes, that is just bad behavior on the control's part that I will need to address. However, there is a good reason why I would not recommend your current approach.

The primary design behind the SRP Schedule Control is that is synchronizes with other schedules across a network. While it is not a necessary feature, it drives all the logic under the hood. So, when you add or remove an appointment, a lot is going on. Everything is indexed, sorted, and arranged to ensure proper synchronicity. So, repeatedly removing everything and re-adding everything comes with significant overhead.

It would be probably be more performant (and consequently less buggy) for you to have multiple Schedule controls: one for each tab. True, this will consume more memory, but unless your loading a few centuries of appointments, I can't imagine it bogging down even older systems.

Meanwhile, I will investigate the crash and see if I can get it to behave like a proper child... er... control should.

AusMarkB

Unfortunately, how a proper child should behave is subject to wide and varied opinion.

I take your point about the amount of overhead involved and suspected as much. In my instance I was not using the control the way it would likely be used in practice but rather just changing various properties and repeatedly reloading to see the affect on the layout/appearance. In userland it would be a one set thing to create a bunch of appointments and then just manipulating them within the control rather than reloading again and again.

Was mainly looking for a best practice guide in case I had a need to make regular changes to the appointment list.

I look forward to the improved behaviour however I suspect Time Out will not suffice in this case.

AusMarkB

and in case it helps, here's one of the error messages I received

jku@amstlc.com

I'm a little late to this party, but have encountered a similar behavior to that described above. In my case, I need to change the entity list based on the schedule date. The primary entity is a truck and it is associated with a driver. Problem is, the driver may not be the same on a truck for all days. So, in order to make the schedule look correct, the associated driver may need to be reset based on the day being displayed. I tried resetting the EntityList property, but, as noted above, this makes the entire OI system crash. I don't need to reset the appointments for a day, just the entity headers. Is there a better way?

DonBakke

Jan,

In your case I suggest just trying to use the Entity property to update the text. Let us know if that works better for you.