Make period a nullable property of reactive timer and clarify documentation #1957
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Ignoring the value of
TimeSpan.Zero
for thePeriod
property is an unfortunate historical legacy. The property should really expose a nullable type when deciding between whichObservable.Timer
overload to call.This PR changes the type signature of
Period
to be a nullable timespan, but retains the same behavior by requiringPeriod
to be larger than zero for periodic timers. We also introduce a slight modification to its serialization behavior to ensure that a value of zero is always serialized asnull
.This will start the migration away from using
TimeSpan.Zero
as a valid value, and might give us some room to consider reinstating the zero period as a high frequency periodic timer for 3.0.We could also introduce an automatic conversion at the level of the editor, but this might break embedded include workflows which happen to be using the old timer semantics, since these are not converted automatically by the editor until they are ungrouped and resaved.
The embedded description string was also fixed for the shaders timer.
Fixes #1947