Variable entities

AusMarkB

Wondering if there is an undocumented AddEntities method?

I find myself in a position where the addition of a new appointment may well need the addition of an entity as well to accommodate the new appointment. Is this possible or would it require resetting the entitylist completely.
If the latter, would resetting the entity list affect the existing appointmentlist that is would I need to recreate that as well after the entitylist property change?

KevinFournier

There is currently no means to add new entities. You would have to reset the EntityList property, which will delete all appointments. Entities should not be changing that often. I recommend creating all the entities in advance and hiding the ones that you don't want to see using the EntityChecked property.

AusMarkB

Thanks Kevin,

I'm still trying to determine how to best represent the data but even in the simplest form there's still a great potential for changing well, mostly adding of entities. Creating all the entities in advance is not really an option in most cases or I could end up with an entitylist 500,000 entities long to cater for an appointmentlist of 150-200.

I will rethink the approach to bring the numbers down. That will mean though, providing an external option to change what I was thinking of having as a group, which is fine but will then lead to regularly changing the appointment list. However, thinking about it, that could leave the entitylist alone regardless.

Can I expect any trouble with regularly replacing the appointmentlist as opposed to adding to it?

DonBakke

I have to ask, what do your entities represent?

AusMarkB

With the simplest representation, people.
It's a casual labour force of which potentially any one person could work at any number of locations on any given day.
I was thinking of having the locations as groups and the individuals as entities but in that mode, to build all entities in advance would require having maybe 300 staff listed under each of maybe 1500 locations. Not really viable. This is just an example of possible numbers but fairly accurate for the database I'm looking at at the moment.
So I will go with just listing all staff as entities and have another means of selecting the location. If the user changes the location, then I'll need to change the appointment list but the entitylist will remain the same.

I'll see how that plays out and then determine if I need to have another rethink.

KevinFournier

That is just too much data to be honest. I think the Schedule control might not be the right fit for this unless you choose to break it down. For example, perhaps you only show 1 department or 1 team at a time. With 300+ entities, users are going to be sitting around for possibly minutes while you load weeks worth of data... unless you plan to only load one day at a time.

AusMarkB

That's helpful info Kevin. You don't really think it's going to deter me though do you? I've toyed with the schedule control on a few occasions over the last n years but have never been able to find an approach that seemed workable no matter how much I wanted to use it. I thought it was just me but it may well have been that it's not the right fit for the size of the datasets I'm working with.

Yes, teams are an option but in this space, they're a preference not an absolute hence the original request about adding entities. These are the five people who normally work here but on any given day any one of the other 300 people we have on the books could be thrown into the mix.

Normally we work weekly/fortnightly so everything currently works out of edittables but a change in direction for a particular customer means that a daily view would be more appropriate and the schedule control is so much nicer to use. It's also the type of view the customer has seen whilst reviewing other products and they like it too.
Interestingly, I made the point at the time of these reviews that all these demos consisted of a handful of staff (entities) and would likely not be nearly as nice or efficient if they were to be implemented with real data.

It was an observation acknowledged as true but it's hard to beat the bells and whistles.

I shall persist. Not dead in the water yet.

KevinFournier

Perhaps it will help not to treat an Entity as a physical person, but as a "working employee." If only 5 or 6 are working at a time, you don't need the other 300+. So, instead of John, Suzy, etc., the entities could be named after a position: Machinist, Operator, Supervisor, etc.

AusMarkB

Has merit. Doesn't fit this case. May well fit for other customers but not for the one that's going to foot the bill.

Assume John, Suzy and the other 300 are equally qualified. They're not but they could be for the job required.

We have a location that regularly requires work. We always send John and Suzy because they live nearby, they know the place, they're experienced and they do good work. They're the preferred team.

Today, that same location calls up and says we need someone this afternoon for four hours. We can't send John or Suzy because they've both been working this morning. We don't turn down the work because we've got ten other people that are available today that normally perform the same functions, just at other locations. Any one of them can go. Potentially any one of the 300 could go if they were available.

Admittedly, those numbers go down when you start considering other factors like geographical regions, qualifications etc so I have to decide the best way to get an accurate subset and then strongly encourage the customer to maintain their data to conform.

Think technician that goes around to houses/businesses to connect up the internet. You have 300 technicians and a whole city of potential customers.

DonBakke

In the spirit of what Kevin was suggesting (which I'm not sure you quite understood), don't make entities keyed to unique people. Create a slate of generic entities...however many you could possibly need for a given site and day. Let's say you pick 20 to give yourself some breathing room. Using a generic ID for each entity (e.g., Person1, Person2...Person20). Then at runtime you assign the actual people who are working to one of these generic entities and change the Title to visually indicate the actual person. Internally you keep a map of the entity to the person so you can add/modify/remove appointments as needed. You can then use Kevin's original suggestion to hide entities that you don't need for a given date.

We have a client that does something similar. He uses the control to track trucks on the road. However, the application also displays the driver's name in the entity. The drivers aren't always driving the same truck each day so the application needed a way to dynamically swap the driver to the truck being driven on a particular day. We make this association on-the-fly based on how the driver is scheduled for each day.

AusMarkB

So you don't show the tree?
Or is there a way to 'hide' unused entities in the tree as well?
I've been assuming perhaps incorrectly that when we're talking about hiding entities we're referring to unchecking the entitychecked property which hides them from the schedule but not the tree.

DonBakke

No, our client shows the tree but the tree shoes the title of the entities so it always looks fine. I don't know of a way to 'hide' unused entities in the tree itself, but is that important? Could you just not label them like "Available Person 5"? Then from the Schedule control you could provide interactive features like a context menu and one option could be "Assign Person" to an available entity.

AusMarkB

Could you just not label them like "Available Person 5"?

I can do anything Don.

DonBakke

Can you teach me that trick?

AusMarkB

Years of practice and a willingness to live in a state of delusion