The Configuration button was made active in this installment. The following changes were made.
- A full complement of Get and Set members were added to the NoteCalculations class. These were simply copied from the original members and the names and icons changed. Front panel controls were copied directly from the class control cluster.
- In the previous version, an error condition during initialization of the sound acquisition loop would cause a hang. This has been fixed in the loop “start” and “stop” cases.
- The configuration dialog concept was modified to include a data analysis time period. The code behind the dialog was then written and the whole thing added to the main library.
- The main code was modified to use the configuration dialog.
- The sound acquisition loop was modified so that no changes to acquisition occur until the apply configuration VI is called. Previously, the object was queried for the number of points taken, which was calculated from the sample rate and acquisition time. This led to incorrect behavior if the sample rate or acquisition time were changed in the configuration while data was being collected. Now the number of points is cached in a shift register and changed when the configuration changes.
- The pulse analysis code was modified to filter out frequencies below 20Hz. See Xyl.lvlib:ConvertNotesToDisplay.vi.
The configuration dialog is a simple dialog pattern. Initialization takes place before an event loop, cleanup afterwards. This design pattern is suitable for simple dialogs. You can already see the scalability limits of this type of design in the large numbers of wires going around the event structure. Use of the sound acquisition and note calculation objects made writing the dialog simple and straightforward. Adding new parameters would not be difficult, but would stretch the ease of maintenance if many more were added. Using a state machine similar to the main program loop is the next step, if this dialog gets too large.
The dialog is modal by design, but is also live — changes to the configuration are immediately applied to see the result. This is why the original configuration is cached so it can be restored on Cancel. An unfortunate side effect of this design is that if an error condition occurs, the user must cancel or change the settings, close the dialog, run again from the main panel, then relaunch the dialog to make changes. There are two straightforward ways to fix this — make the dialog nonmodal or add a restart button to the dialog. Making the dialog nonmodal is easiest, but then the user can lose it behind the main window. Adding a restart button creates a more complex dialog. I am tending to the second option. What do you think?
Note that the dialog close events are discarded by the event structure and handled as if the dialog were cancelled. Cleanup is then properly handled.
Tabbing between controls does not work well with this dialog. Programmatic tabbing would be a good option, due to the presence of the tab control. Setting the tab order using the Edit»Set Tabbing Order... menu item is not easy due to the presence of the tab control.
Neither the OK or Cancel buttons are mapped to the keyboard at the moment. The OK button is usually mapped to <Return>, but this leads to frustration when filling out the dialog. So this binding was removed.
As always, comments and suggestions are welcome and encouraged.
Previous Installments
