Consider converting text boxes to NumericUpDown editors

[bparks13]

Specifically in Rhs2116StimulusSequenceDialog, consider changing all editors from text boxes to NumericUpDown editors. This allows logic to be embedded in the editor to define minimum and maximum values, and also could allow for easier adjusting.

For time-based properties, the ticks can be based on some discrete number of samples per tick (i.e., one sample is ~33 ms, so one tick could be set to 3 samples, which would be ~100 ms). This can also be updated dynamically if the scale is on the order of tens of seconds.

For amplitude-based properties, the ticks can be based on the current step size, and each tick is one sample of the current step size.

[bparks13]

Question from the issue sorting meeting: Does the NumericUpDown editor allow floating points?

Prototype this with a single text box and see how it looks before implementing all of them.

[bparks13]

Testing NumericUpDown

It is possible to set a NumericUpDown editor with a decimal point value (note: decimal, not double). We can control the number of decimal places displayed (from 0 on up), as well as the increment step size.

However, the increment and the value are both decimal types, and we are currently calculating the period for a single step using double:

const double SamplePeriodMilliSeconds = 1e3 / Rhs2116.SampleFrequencyHz;

Based on this post, we can explicitly cast to decimal from double, but we might lose information due to the conversion. Therefore, it might not be the correct method to move forward in this way and directly convert a TextBox to a NumericUpDown.

Alternative to Directly Replacing TextBox's

Instead of attempting to keep track of the exact value of the sample period in the NumericUpDown, we could instead separate the number of samples from the physical representation by having the user manipulate the NumericUpDown editor and have the physical time conversion displayed in a read-only TextBox:

(note that values here are not necessarily real, just showing the visualization)

In this way, we can directly track of the number of samples/steps that we use in the Rhs2116StimulusSequence by the value of the NumericUpDown, so no need to worry about rounding errors or conversions.

To make this more clear, we would probably need to update the labels so that it is clear that the NumericUpDown is the number of samples, while the TextBox is the actual time in [ms].

Loss of Ability to Write Specific Parameters?

One potential issue is that right now have the ability to only write specific parameters to a channel by checking if there is any input in the TextBox; an empty field means that the value is skipped when writing to the stimulus sequence. There is no concept of an "empty" NumericUpDown; it always has a value associated with it. This could lead to situations where a value is written to a channel when it was not supposed to be.

Potential Changes to Amplitude

We also previously removed the ability for the user to set the amplitude step size manually, instead opting for an algorithm to search through all of the requested amplitudes and determine an optimum step size that encompassed all possible values. If we change to using the NumericUpDown, the user is not giving an absolute amplitude, but rather the number of steps with the given step size.

Should we then make the amplitude step size editable by the user? So they can modify the steps and step size independently?

[bparks13]

It is also important to note that there are significant changes to the architecture of the Design library in #459, which adds the concept of a GenericStimulusSequenceDialog and splits the Rhs2116StimulusSequenceDialog into a class that inherits the generic class, and also a Rhs2116StimulusSequenceOptions that holds these options in a separate dialog. It may be prudent to wait until that is finished and merged before this is started, otherwise merging may be a messy conflict.