There were a few questions in the community forums lately related to some kind of inconsistency in how statuscode optionset behaves, so I figured I’d do a bit of testing tonight.
Here is the set up:
- I created a new custom entity
- Added two additional status reasons
- And, also, added a new option set field
Here is how the form looks like:
I’m going to see how option set control methods work in different situations.
1. Test 1
I’m going to set statuscode and custom field value in the onload of the form:
Here is the result – everything’s good so far:
2. Test 2
I’m going to clear option statuscode and option set control options, then add them programmatically, then set field values:
Here is the result:
That’s exactly why those questions were asked – do you see how my custom field has a value, yet Status Reason is still empty?
3. Test 3
Let’s use the good old setTimeout and see if that changes anything
And here is the result now:
Cool, huh?
I actually have no idea why it’s like that, but I’m assuming there is something about statuscode that makes it different from all other option sets. Maybe it’s the state transitions:
https://msdn.microsoft.com/en-us/library/dn689032.aspx
I did not have any of those defined, though.
Maybe it’s the fact that statuscode is dependent on the statecode. Maybe both.
Either way, it seems that, unlike other option set controls/attributes, statuscode control needs a bit of time for the initialization once you have used those optionset-specific methods such as clearOptions, addOption, etc. You can give it that time by introducing a timeout which does not have to be that big at all, it just have to be there, and, after that timeout, statuscode is back in business.
Happy 365-ing!